Resumen SEBoK V2 30-07-2018

RESUMEN
INCOSE
SYSTEMS ENGINEERING
HANDBOOK
MIS-MTS
CONAE UFS-UTN
1
Resumen INCOSE SEBoK MIS-MTS-2018
Contenido
CAPÍTULO 2: CONCEPTOS DE INGENIERÍA EN SISTEMAS 5
2.1 Introducción 5
2.2 Definiciones 5
2.1.1 Sistemas 5
2.1.3 Contexto 5
2.1.4 Funcionalidad 5
2.1.5 Arquitectura 5
2.1.6 Atributos 5
2.2 Jerarquía dentro de un sistema 6
2.4 Sistema de sistemas (SoS) 6
2.5 Sistemas de Habilitación 7
2.6 Definición de Ingeniería de Sistemas 7
2.7 Origen y Evolución de la SE 7
2.8 Aplicación y valor de la ingeniería en sistemas 8
2.9 Ciencia de los sistemas y el pensamiento científico 9
2.9.1 Ciencia de los sistemas 9
2.9.2 Pensamiento sistémico (System Thinking) 9
2.10 Liderazgo de la Ingeniería de Sistemas 9
2.11 Desarrollo Profesional de la ingeniería en sistemas 10
CAPÍTULO 3: CICLO DE VIDA DE UN SISTEMA 11
3.1 Introducción 11
3.2 Características 11
3.3 Puntos de decisión (KPD) 11
3.4 Etapas del ciclo de vida 12
3.5 Modelos de ciclo de vida 12
3.6 Criterio de selección de procesos 15
CAPÍTULO 4: PROCESO TÉCNICO 16
4.1 Proceso de análisis de misión o de negocio 18
4.2 Proceso de definición de los requerimientos y necesidades de los interesados 19
4.3 Proceso de definición de los requerimientos del sistema 20
4.4 Proceso de definición de la arquitectura 21
4.5 PROCESO DE DEFINICIÒN DEL DISEÑO 23
4.6 PROCESO DE ANÁLISIS DEL SISTEMA 24
4.7 PROCESO DE IMPLEMENTACIÓN 25
4.8 PROCESO DE INTEGRACIÓN 25
4.9 PROCESO DE VERIFICACIÓN 27
CAPÍTULO 5: PROCESOS DE LA GESTIÓN TÉCNICA 45
5.2 Evaluación y Control de los Procesos del Proyecto 45
2
5.4 Proceso de gestión de riesgos 46

5.5 Proceso de Gestión dE configuración 46
5.6 Proceso de gestión de la información 46
5.7 Proceso de medición 46
CAPÍTULO 6: PROCESOS DE ACUERDOS 47
6.1 Proceso de adquisición 47
6.2 Proceso de suministro 47
CAPÍTULO 7: PROCESOS ORGANIZATIVOS DE HABILITACIÓN DE PROYECTOS 48
7.1 Proceso de Gestión del Modelo de Ciclo de Vida 48
7.2 Proceso de Gestión de Infraestructuras 49
7.3 Proceso de Gestión de Portafolios 50
7.4 Proceso de Gestión de Recursos Humanos 51
7.5 Proceso de Gestión de Calidad 52
7.6 Proceso de Gestión del Conocimiento 53
CAPÍTULO 8: PROCESO DE ADAPTACIÓN Y APLICACIÓN DE INGENIERÍA DE SISTEMAS
55
8.1 Proceso de Adaptación 56
8.2 Adaptación a un Producto o Área de Aplicación Específico 57
8.2.5 Sistemas espaciales 57
8.3 Aplicación de la Ingeniería en Sistemas en el Manejo de Lineas de Productos 58
8.4 Aplicación de la Ingeniería en Sistemas para Servicios 59
8.4.4 Valor de la SE en servicios 59
8.5 Aplicación de la Ingeniería en Sistemas para Empresas 60
8.6 Aplicación de la Ingeniería en Sistemas para PyMEs 60
CAPÍTULO 9: CROSS-CUTTING SYSTEM ENGINEERING METHODS 61
9.1 Modelos y Simulaciones 61
9.1.1 Modelos versus Simulaciones 61
9.1.2 Propósitos del Modelo 61
9.1.3 Alcance del Modelo 61
9.1.4 Tipos de Modelos y Simulaciones 62
9.1.4.1 Tipos de Modelos 62
9.1.4.2 Tipos de Simulaciones 63
9.1.5 Desarrollando Modelos y Simulaciones 63
9.1.6 Integración del Modelo y la Simulación 63
9.1.7 Gestión del Modelo 63
9.1.8 Modelos Estandars 63
9.1.9 Lenguajes de Modelado 63
9.1.10 Herramientas de Modelado y Simulación 65
9.1.11 Indicadores de calidad del Modelo 65
3
9.1.12 Modelo y Métricas basadas en Simulación 65

9.2 Ingeniería de Sistemas Basada en Modelos (MBSE) 65
9.3 Método de Ingeniería de Sistemas Basada en Funciones (FBSE) 66
9.4 Método de Ingeniería de Sistemas Orientado a Objetos (FBOO) 67
9.5 Creación de Prototipos 68
9.6 Gestión de Interfases 68
9.7 Desarrollo de Productos Integrados y Procesos 69
9.8 Lean SE 70
9.9 SE Ágiles 70
CAPÍTULO 10: ACTIVIDADES ESPECIALES DE LA INGENIERÍA 72
10.1 Análisis de Asequibilidad, de Costo-Efectividad y costo de ciclo de vida 72
10.1.1 Análisis de Asequibilidad 72
10.1.2 Análisis de Costo-Efectividad 73
10.1.3 Análisis de Costo de Ciclo de Vida (LCC) 73
10.2 Compatibilidad Electromagnética 74
10.3 Ingeniería Ambiental y Análisis de Impacto 74
10.4 Análisis de Interoperabilidad 74
10.5 Ingeniería de Logística 75
10.5.1 Análisis de Compatibilidad 75
10.6 Análisis de Fabricación y Productividad 75
10.7 Ingeniería de Propiedades de Masa 76
10.8 Confiabilidad, Disponibilidad y Mantenimiento 76
10.8.1 Confiabilidad 76
10.8.2 Disponibilidad 77
10.8.3 Mantenibilidad 77
10.9 Ingeniería de Resiliencia 77
10.10 Ingeniería de Seguridad (SAFETY) del Sistema 78
10.11 Ingeniería de Seguridad (Security) del Sistema 78
10.12 Análisis de Necesidades de Capacitación 78
10.13 Análisis de Utilización / Integración de sistemas humanos 79
10.14 Ingeniería de Valores (VE) 79
4
CAPÍTULO 2: CONCEPTOS DE INGENIERÍA EN

SISTEMAS
2.1 INTRODUCCIÓN
En este capítulo se verán brevemente los principales conceptos referidos a la Ingeniería en

Sistemas (SE), un repaso por su historia y las ventajas de su aplicación.
2.2 DEFINICIONES
2.1.1 Sistemas
Las definiciones de sistema según INCOSE e ISO / IEC / IEEE:
Conjunto integrado de elementos, subsistemas o ensambles que logran un objetivo definido.

Estos elementos pueden incluir productos (hardware, software, firmware), procesos, personas,
información, técnicas, instalaciones, servicios y otros elementos de apoyo. (INCOSE).
Combinación de elementos que interactúan organizadamente para lograr uno o más propósitos
establecidos. (ISO / IEC /IEEE 15288).
2.1.3 Contexto
Una vista externa de un sistema debe introducir elementos que específicamente no
pertenecen al sistema pero que sí interactúan con el sistema Esta colección de elementos es
llamada el entorno operativo o contexto y puede incluir a los usuarios (u operadores) del
sistema.
Las vistas internas y externas definen el concepto de frontera del sistema. Es una “línea de
demarcación” entre el sistema mismo y su contexto (ambiente operativo) definiendo que cosas
pertenecen al sistema y que no.
2.1.4 Funcionalidad
La funcionalidad de un sistema está expresada típicamente en términos de interacciones del
sistema con su ambiente operativo, en especial los usuarios.
2.1.5 Arquitectura
La arquitectura de un sistema se define como el concepto fundamental o las propiedades de
un sistema en su entorno incorporado en sus elementos, relaciones y en el principio de su
diseño y evolución.
2.1.6 Atributos
Un atributo de un sistema (o de un elemento del sistema) es una característica o propiedad
observable del sistema (o de elemento del sistema). Un sistema entonces, está representado
por los atributos (externos) del sistema, sus atributos internos y estructura, y las relaciones
entre estos que son gobernados por las leyes de la ciencia.
5
2.2 JERARQUÍA DENTRO DE UN SISTEMA
Se define como una partición del sistema donde cada elemento del mismo puede ser atómico
(aquel elemento por el cual no puede ser descompuesto o particionado), o puede ser otro
sistema dentro del sistema en estudio. Estos elementos son agrupados en distintos
subconjuntos de elementos subordinados a un sistema de más alto nivel. Se sugiere no tener
más de 7±2 elementos subordinados por cada nivel en la jerarquía (Urwick 1956).
2.4 SISTEMA DE SISTEMAS (SOS)
Es un sistema de interés (SOI) cuyos elementos son operados/gestionados

independientemente. Ejemplo: sistema de transporte que comprende el sist. Transp. Terreno,
marítimo ó aéreo.
La mejor manera de entender un sistema complejo es romperlo recursivamente en partes

simples que puedan entenderse y entonces, re ensamblar las partes para entender el todo.
Los siguientes desafíos influyen en la ingeniería de un sistema de sistemas:
● Autoridades: Cada uno de los sistemas que constituye el SoS tiene un propietario
local con sus usuarios, proceso de negocio y enfoque de desarrollo. En un SoS la
ingeniería en sistema se basa en un análisis transversal y composición e integración de
cada sistema constituido. Debe permitir trabajar juntos hacia un objetivo colectivo que
puede o no coincidir con los objetivos individuales de cada sistema.
● Liderazgo: Esta cuestión del liderazgo se experimenta cuando la falta de control

estructurado normalmente presente en ingeniería de sistemas requiere alternativas
para proporcionar coherencia y dirección, como influencia e incentivos.
● Perspectiva de los sistemas constituidos: Los SoS están compuestos típicamente,

al menos en parte, de sistemas en servicio, que a menudo se desarrollaron para otros
6
fines y ahora se aprovechan para cumplir una nueva o diferente aplicación con nuevos
objetivos.
● Capacidades y requerimientos: Típicamente cada Sistema múltiple del SoS presenta

su propio conjunto de requerimientos. En otros casos se necesita agregar ó cambiar los
requerimientos en base a necesidades, y esto se logra a través de cambios en el
sistema constituido o agregando otro sistema al SoS.
● Autonomía, interdependencia y emergencia: La independencia de los sistemas

constituyentes en un SoS es la fuente de una serie de problemas técnicos que enfrenta
SE de SoS. Aumenta la complejidad, conduce a comportamiento imprevisto e
impredecible en un SoS.
● Testeo, validación y aprendizaje: Puede ser muy difícil evaluar el nivel de

rendimiento como base para determinar las áreas que requieren atención o para
garantizar a los usuarios las capacidades y limitaciones del SoS. A menudo, la única
forma de obtener una buena medida del rendimiento del SoS es a partir de los datos
recopilados de las operaciones reales o mediante estimaciones basadas en modelos,
simulaciones y análisis.
● Principios del SoS: SoS es un área relativamente nueva, Se necesita trabajo para
identificar y articular los principios transversales que se aplican a SoS en general y
para desarrollar ejemplos de trabajo de la aplicación de estos principios.
2.5 SISTEMAS DE HABILITACIÓN
Estos son sistemas que facilitan las actividades del ciclo de vida del sistema de interés (SOI).
Estos proveen servicios que son necesarios para el SOI durante una o más etapas del ciclo de
vida. Ejemplos de estos sistemas son Sistemas de desarrollo colaborativo, Sistemas De
producción, Sistemas de soporte logístico, etc. La relación entre los sistemas habilitadores y el
SOI puede ser bilateral o donde el SOI simplemente recibe los servicios que necesita en el
momento que los requiere
2.6 DEFINICIÓN DE INGENIERÍA DE SISTEMAS
Según INCOSE, la Ingeniería en Sistemas es una actividad interdisciplinaria que busca la

realización de sistemas exitosos. Se centra en definir las necesidades de los clientes,
determinar las funcionalidades en fases tempranas del desarrollo, documentar los
requerimientos y llevar a cabo el diseño y validación considerando todos los aspectos
involucrados.
La ingeniería en sistemas debe considerar tanto las necesidades técnicas como de negocios
de los clientes de manera tal de poder proveer de un producto de calidad que satisfaga sus
necesidades.
2.7 ORIGEN Y EVOLUCIÓN DE LA SE
La Ingeniería en Sistemas moderna tiene sus inicios en los años 30 con la formación de un
equipo multidisciplinario cuyo fin era analizar el sistema de defensa aérea británica.b Sus
primeras aplicaciones fueron en el área militar y luego se fue trasladando a la actividad
académica e industrial.
7
En 1990 se crea el Consejo Nacional de Ingeniería en Sistemas (NCOSE), tomando carácter

internacional en el año 1995 (INCOSE). En el año 2012 esta entidad publicaría el SEBoK.
En el año 2002, con la introducción del estándar internacional ISO/IEC 15288 la ingeniería en
sistemas se estableció cómo el mecanismo preferido para la creación de productos y servicios
entre dos o más organizaciones.
2.8 APLICACIÓN Y VALOR DE LA INGENIERÍA EN SISTEMAS
La ingeniería en sistemas surgió como una forma efectiva de controlar la complejidad y los
cambios propios de un proyecto. La experiencia dicta que el costo de ciclo de vida (LCC) a la
hora de corregir errores, es mayor a medida que avanza el proyecto lo que también implica la
importancia que tiene el tener buena información y análisis a la hora de tomar las primeras
decisiones. Esto puede observarse en la siguiente imagen:
8
2.9 CIENCIA DE LOS SISTEMAS Y EL PENSAMIENTO CIENTÍFICO
2.9.1 Ciencia de los sistemas

La ciencia de sistemas reúne la investigación en todos los aspectos de un sistema con el
objetivo de identificar, explorar y comprender patrones de complejidad que abarcan campos
disciplinarios y áreas de aplicación. Busca desarrollar fundamentos interdisciplinarios que
puedan formar la base de teorías aplicables a todos los tipos de sistemas, independientemente
del tipo de elemento o aplicación; además, podría formar los cimientos de una metadisciplina
que unifica las especialidades científicas tradicionales.
2.9.2 Pensamiento sistémico (System Thinking)

El pensamiento sistémico se refiere a comprender o intervenir en situaciones problemáticas,
basándose en los principios y conceptos del paradigma de sistemas.
El pensamiento de sistemas considera las similitudes entre los sistemas de diferentes dominios
en términos de un conjunto de conceptos, principios y patrones de sistemas comunes:
Un principio es una regla de conducta o comportamiento. Para llevar esto más allá, un principio
es una "generalización básica que se acepta como verdadera y que puede usarse como base
para el razonamiento o la conducta".
La aplicación práctica del pensamiento sistémico a menudo emplea el uso de representaciones

o modelos de sistemas abstractos.
2.10 Liderazgo de la Ingeniería de Sistemas

Existen diferencias entre un líder y un gerente. Tanto el liderazgo cómo la administración, son
dos aspectos muy importantes en la SE y cada uno tiene distintas relevancias según la fase del
proyecto que se aborde. Por esta razón, el líder de Ingeniería de Sistemas debe tener una
visión que tenga en cuenta el contexto, los límites, las interrelaciones y el alcance de los
sistemas. También debe servir cómo un modelo de adaptabilidad, agilidad y resistencia tanto
del sistema cómo de los equipos que lo desarrollan.
● Reconocer que es lo que genera comportamiento en la estructura del sistema

(elementos y sus relaciones).
● Observar como los elementos dentro del sistema cambian en función del tiempo,
generando patrones y tendencias.
● Identificar la causa y el efecto de las relaciones.
● Cambiar de perspectiva para incrementar el entendimiento del sistema.
● Comprobar el resultado y realizar cambios en las acciones si es necesario.
La ingeniería de sistemas es un enfoque multidisciplinario y significa permitir la realización de
sistemas exitosos. Los sistemas exitosos deben satisfacer las necesidades de sus clientes,
usuarios y otras partes interesadas (stakeholders). Algunos elementos clave de la ingeniería de
sistemas se destacan en la Figura e incluyen:
9
Un ingeniero de sistemas es una persona o rol que apoya este enfoque multidisciplinario. En
particular, el ingeniero de sistemas a menudo sirve para obtener y traducir las necesidades del
cliente en especificaciones que pueden ser realizadas por el equipo de desarrollo del sistema.
Para ayudar a realizar sistemas exitosos, el ingeniero de sistemas admite un conjunto de

procesos de ciclo de vida que comienzan temprano en el diseño conceptual y continúan
durante todo el ciclo de vida del sistema a través de su fabricación, despliegue, uso y
eliminación. El ingeniero de sistemas debe analizar, especificar, diseñar y verificar el sistema
para garantizar que sus características funcionales, de interfaz, de rendimiento, físicas y otras
características de calidad, así como los costos, se equilibren para satisfacer las necesidades
de los interesados del sistema.
2.11 DESARROLLO PROFESIONAL DE LA INGENIERÍA EN SISTEMAS
Un ingeniero en sistemas necesita saber que habilidades le permitirán ser más efectivo. Las
mismas pueden alcanzarse normalmente con un 70% de experiencia, 20% a través de
mentores y 10% con entrenamiento. Mientras el entrenamiento brinda los conceptos básicos,
los mentores pueden orientar correctamente el desarrollo del conocimiento a través de la
experiencia.
10
CAPÍTULO 3: CICLO DE VIDA DE UN SISTEMA
3.1 INTRODUCCIÓN
Un ciclo de vida puede ser definido como una serie de etapas a través el cuál algo (un sistema
o producto fabricado) pasa. El rol del ingeniero en sistemas engloba el ciclo de vida entero para
un sistema de interés, desarrollando una solución desde la definición de los requerimientos a
través del diseño, construcción, integración, verificación, operación y finalmente el retiro del
sistema. Se asegura que los expertos de dominio estén involucrados adecuadamente.
Persiguiendo todas las oportunidades de ventajas, identificando riesgos y mitigarlos.
El ingeniero en sistema trabaja muy de cerca con el Project manager en el ciclo de vida,
incluyendo puntos de decisión, conociendo las necesidades de su proyecto específico.
3.2 CARACTERÍSTICAS
Todo ciclo de vida de un sistema consiste de múltiples aspectos, incluyendo los de negocio
(comerciales), de presupuestos (fondos) y técnicos (producto). La ingeniería de sistema crea
soluciones técnicas consistentes con los aspectos comerciales y restricciones de fondos. La
integridad del sistema requiere que estos tres aspectos estén balanceados y debe dársele igual
énfasis durante todas las revisiones.
3.3 PUNTOS DE DECISIÓN (KPD)
Se conocen como puntos de control (revisiones), son eventos de aprobación en el ciclo del
proyecto, suficientemente importantes a ser definidos e incluidos en el programa por el Project
manager, executive management o el cliente. Estos puntos de decisión aseguran que nuevas
actividades no serán propuestas hasta que las actividades previas del programa sean
satisfactoriamente completadas y ubicadas bajo control de configuración.
Estas revisiones representan los principales puntos de decisión en el ciclo de vida de un
sistema. Sus objetivos principales son:
● Asegurar que la elaboración de las bases técnicas y comerciales son aceptables. De

esta manera satisface la verificación y validación (V&V)
● Asegurar que los pasos siguientes sean realizables y el riesgo de proceder es
aceptable.
● Fomentar el trabajo en equipo continuo entre el comprador y el vendedor.
● Sincronizar las actividades del proyecto.
11
3.4 ETAPAS DEL CICLO DE VIDA
Un sistema progresa a través de ciertas etapas en el ciclo de vida ayudando y asegurando que
el sistema cumpla su funcionalidad requerida.
Hay seis etapas genéricas en el ciclo de vida:
● Concepto: Define el espacio del problema, caracterizando una solución viable,

identifica los interesados y clientes, explora ideas y tecnologías. Refinamiento de
necesidades de los interesados.
● Desarrollo: Define/refina los requerimientos del sistema. Crea la descripción de la
solución (arquitectura y diseño). Implemente al sistema inicial. Integra, verifica y valida
el sistema.
● Producción: El sistema produce. Inspección y verificación.
● Utilización: El sistema opera para satisfacer las necesidades del cliente.
● Soporte: Provee servicios que habilita la operación continua. Modificaciones pueden
ser propuestas para reducir costo operacional o extender la vida del sistema.
● Retiro: En esta etapa es donde el sistema y sus servicios relacionados son removidos
de la operación.
Ciclo de vida de un instrumento satelital:
3.5 MODELOS DE CICLO DE VIDA
Varios modelos de ciclos de vida como el cascada, incremental iterativo, espiral y Vee son
útiles para definir apropiadas actividades en las etapas al inicio, al final y durante el proceso en
el ciclo de vida.
A menudo, la definición de un sistema es vista como un proceso de pasos simples lineales y
secuenciales. Sin embargo, la información de valor y las ideas necesarias deben ser
intercambiadas llevando un orden para asegurar una buena definición del sistema que
efectivamente cumpla la misión o necesidades comerciales.
- Iteración y recursión: Son aplicaciones repetitivas mediante lazos de realimentación
apropiados y permiten garantizar una comunicación que tenga en cuenta el aprendizaje
contínuo y las decisiones. La iteración es la repetición de la interacción entre dos o más
procesos en un dado nivel en la estructura del sistema o jerarquía. La iteración es
necesaria para acomodar las decisiones de los interesados (clientes) y evolucionar el
entendimiento, tomar decisiones/restricciones arquitecturales y resolver los conflictos
de accesibilidad, adaptabilidad, factibilidad, resiliencia etc.
La recursión es una aplicación repetitiva de la interacción del proceso en sucesivos
niveles en la estructura del sistema.
- Método incremental e iterativo: es un mecanismo práctico de desarrollo de un
proyecto por el cual permite tener la habilidad inicial de realizar entregas sucesivas
para obtener el sistema de interés. El punto principal es obtener una rápida respuesta y
adaptabilidad. El método es usado cuando los requerimientos no son claros desde un
principio o cuando los interesados (clientes) desean mantener el sistema de interés
abierto para la posibilidad de insertar nuevas tecnologías. El proyecto recibe continua
realimentación desde los interesados para obtener una rápida respuesta y así
satisfacer las altas necesidades de los clientes.
- Secuencial (cascada): este método está caracterizado por proveer disciplina al
proceso del ciclo de vida y dar un acercamiento sistemático al representar a un proceso
12
específico como la evolución del sistema a través de una serie de representaciones

que van desde los requerimientos pasando por el diseño hasta el producto finalizado.
Las fortalezas del método son la predictibilidad, estabilidad, repetitividad y alta
garantía.
- El modelo Vee: es un método secuencial usado para visualizar varios tipos de áreas
en los que se enfoca la ingeniería de sistema, particularmente durante las etapas
conceptuales y de desarrollo. El modelo ilustra las actividades de la ingeniería de
sistema durante las etapas del ciclo de vida.
El modelo Vee describe las actividades y resultados que deben producirse durante el
desarrollo de un producto. El lado izquierdo de la V representa la descomposición de
las necesidades, y la creación de las especificaciones del sistema.
13
El lado derecho de la V representa la integración de las piezas y su verificación.
Un atributo clave de este modelo es el tiempo y la madurez del proceso se mueve de

izquierda a derecha a través del diagrama.
En cualquier instante de tiempo el equipo de desarrollo puede mover su perspectiva en
la flecha vertical desde el más alto nivel al más bajo nivel.
- Minimiza los riesgos del proyecto.
- Transparencia y control del proyecto.
- Mejora la calidad.
- Reducción de gastos totales (reduce la dependencia de los proveedores y el
esfuerzo para las siguientes actividades y proyectos).
- Mejora la comunicación.
14
3.6 CRITERIO DE SELECCIÓN DE PROCESOS
El pensamiento sistémico y la SE asegura que el diseño del sistema se adapte apropiadamente

a las necesidades de los clientes. La aplicación efectiva de la SE radica en generar un
ambiente donde se empleen efectivamente los talentos creativos e inventivos de modo tal de
desarrollar el sistema con el menor costo administrativo posible.
Sin embargo, es imposible encontrar una configuración de procesos que sirva para cualquier
situación, por lo que la selección del mismo se verá afectada tanto por los componentes del
proceso (actividades, productos, agentes, herramientas) y sus interacciones (flujo de
información, control, comunicación).
15
CAPÍTULO 4: PROCESO TÉCNICO

Los procesos técnicos son usados para definir los requerimientos para un sistema, para
transformar los requerimientos en un producto efectivo, para permitir la reproducción
consistente del producto cuando sea necesario, para proveer los servicios requeridos, para
sostener la provisión de estos servicios hasta que el producto sea retirado.
El proceso técnico permite la interacción coordinada entre el ingeniero en sistema con
ingenieros especialistas de distintas disciplinas, con los interesados del sistema, operadores y
fabricantes.
Sin el proceso técnico el riesgo de que el proyecto falle es altamente probable.
La ISO/IEC/IEEE 15288 incluye 14 procesos técnicos que se describen brevemente a
continuación:
1. Proceso de análisis de misión o de negocio: Se definen los requerimientos de

negocio o problemas y oportunidades de la misión, caracteriza y determina las
potenciales soluciones, evalúa soluciones alternativas, gestiona el negocio o el análisis
de misión.
2. Proceso de definición de los requerimientos y necesidades de los interesados:
Transforma las necesidades de los interesados (entidad individual u organización) a
través de un proceso de ingeniería de requerimientos en requerimientos de los
interesados. Analiza y gestiona estos requerimientos.
3. Proceso de definición de los requerimientos del sistema: Los requerimientos de los
interesados son transformados a través de un proceso de ingeniería de requerimientos
en un conjunto de requerimientos de sistema. Estos requerimientos especifican las
características del sistema, atributos, funciones y el desempeño del sistema. Cada
requerimiento acarrea un costo y los cambios en los mismos tienen un impacto
significante en el costo del proyecto.
4. Proceso de definición de la arquitectura: Se definen arquitecturas alternativas para
el modelo del sistema y una es seleccionada. Las características de la arquitectura
deben satisfacer en lo posible el conjunto de requerimientos del sistema (trazables para
la misión/negocio y los requerimientos del cliente) y el ciclo de vida. El proceso de
selección de la arquitectura es iterativo y se requiere la participación de ingenieros en
sistemas, diseñadores y especialistas en el dominio del sistema. Se selecciona la
tecnología adecuada y los elementos del sistema. El proceso continúa recursivamente
aplicado a la definición de los requerimientos de cada elemento del sistema.
5. Proceso de definición del diseño: Provee suficientes datos e información de detalle
acerca del sistema y de sus elementos para su implementación. El diseño afecta a
cada elemento del sistema (mecánico, electrónico, software, químico, operaciones
humanas y servicios). Las características del diseño incluyen dimensiones, formas,
materiales y estructura de procesamiento de datos. El diseño incluye dibujos,
diagramas, ecuaciones, tablas de métricas con sus valores y márgenes, patrones,
algoritmos, etc.
6. Proceso de análisis del sistema: Este proceso ejecuta una evaluación y estimación
cualitativa basadas en análisis tales como análisis de costo, análisis de conformidad,
análisis de riesgo técnico, análisis de viabilidad y otras características de calidad
crítica. Estos análisis usan principalmente técnicas de modelado cuantitativo, modelos
analíticos, y simulaciones asociadas, que son aplicadas a varios niveles de rigurosidad
y complejidad dependiendo del nivel de fidelidad necesitado.
7. Proceso de implementación: Este proceso crea o fabrica un elemento del sistema
conforme a su descripción (requerimientos, diseño, arquitectura, interfaces). El
elemento se fabrica empleando tecnología apropiada (materiales, procesos adecuados,
estándares) y prácticas industriales.
16
8. Proceso de integración: La integración consiste de un progresivo ensamble de los

elementos (hardware, software y recursos operacionales) que conforman el sistema de
interés. Hay un fuerte enfoque en las interfaces para lograr la interoperación todos
elementos. El proceso de integración trabaja en conjunto con los procesos de
verificación y validación (V&V) comprobando que los límites del sistema (interfaces
físicas, lógicas y sus interacciones) han sido correctamente identificados y descriptos
para satisfacer los requerimientos de diseño y restricciones.
9. Proceso de verificación: Es una instancia de verificación aplicada a un sistema de
interés y sus elementos asociados para establecer que estos han sido construidos
correctamente verificando que errores/defectos/fallas no hayan sido introducidos. Es
una actividad transversal a cada etapa del ciclo de vida del sistema. En particular
durante el desarrollo del sistema, la verificación aplica a cualquier actividad y producto
resultante de la actividad.
10. Proceso de transición: Gestiona la transición del sistema para proveer servicio
especificado por los requerimientos del cliente en un ambiente operacional. La
planificación de la transición incluye estrategias de soporte logístico, capacitación del
operador, estrategias de entrega, estrategias de resolución de problemas.
11. Proceso de validación: Es un proceso que se aplica a un sistema de interés y sus
elementos asociados y permite validar los requerimientos de los interesados
cumpliendo y satisfaciendo sus necesidades en el ambiente operacional. Las técnicas
de validación son las mismas que para la verificación pero el propósito es diferente; La
verificación comprueba los requerimientos del sistema mientras que la validación
comprueba que los requerimientos del sistema satisfacen los requerimientos del
cliente.
12. Proceso de operación: Usa el sistema para la entrega y la sostenibilidad de sus
servicios. Planifica y ejecuta las operaciones, suministra personal para operar el
sistema, monitorear el desempeño del sistema, gestiona los resultados de la operación,
gestiona acciones de contingencia planificadas ante condiciones operacionales
anormales, brinda soporte al cliente.
13. Proceso de mantenimiento: Incluye actividades para gestionar aquellos problemas
que sean identificados y brindar acciones preventivas y correctivas para restaurar el
sistema completo, reportes de anomalías, planificación de futuros mantenimientos.
Gestiona resultados del mantenimiento y la logística.
14. Proceso de eliminación: Tiene como propósito finalizar la existencia de un sistema o
elemento de un sistema, reemplazarlos o removerlos. Incluye los pasos necesarios
para llevar el sistema a una condición aceptable. Está relacionado con el proceso de
mantenimiento.
A continuación se procederá a presentar de manera más detallada cada una de estas

actividades.
17
4.1 PROCESO DE ANÁLISIS DE MISIÓN O DE NEGOCIO
4.1.1 Propósito
Este análisis busca definir los problemas, oportunidades de una misión o negocio, caracterizar
las posibles soluciones y que problemas u oportunidades vienen aparejados con cada una.
4.1.2 Proceso
Este análisis da inicio al ciclo de vida del Sistema de Interés y tiene el siguiente diagrama de
entrada/salida:
Entradas
- Plan estratégico de la Organización

- Concepto de Operaciones (ConOps): Define la arquitectura de trabajo de la
Organización. No debe confundirse con el OpsCon que define las operaciones de un
sistema.
- Documentación fuente.
- Limitaciones en el ciclo de vida
- Limitaciones en el proyecto
- Trazabilidad de los requerimientos delos interesados.
Actividades
- Preparar el análisis de la misión o del negocio: establecer la estrategia del análisis

incluyendo los requerimientos drivers necesarios.
- Definir el espacio de problemas y oportunidades: describir los problemas u
oportunidades teniendo en cuenta los objetivos de la misión y asegurarse que todos
entiendan adecuadamente estas descripciones.
18
- Caracterizar el espacio de soluciones: se debe nominar los actores que deberán

buscar determinada solución, definir un OpsCon y cronograma preliminar y establecer
las alternativas para solucionar cada problema.
- Evaluar los distintos tipos de soluciones: analizar todas las alternativas, tomar una
de ellas cómo favorita y analizar su fiabilidad (modelar, simular, etc) respecto a los
objetivos de la misión.
- Administrar el análisis de la misión o negocio: establecer y mantener la trazabilidad
de los resultados del análisis, así como los requerimientos y cronogramas preliminares.
También se provee la información base para armar la administración de la
configuración.
4.2 PROCESO DE DEFINICIÓN DE LOS REQUERIMIENTOS Y NECESIDADES DE LOS INTERESADOS
4.2.1 Propósito
Este proceso permite definir los requerimientos de un sistema que permita satisfacer las
necesidades de los usuarios y otros actores.
4.2.2 Proceso
Actividades
- Prepararse para la definición de necesidades y requerimientos de los

interesados: Determinar cada interesado que participará en la definición de los
distintos requerimientos a cumplirse durante el ciclo de vida del proyecto.
Normalmente, identificar a los dueños y los usuarios del sistema es relativamente
fácil, sin embargo también se deben tener en cuenta agencias reguladoras y otrs
19
actores que pueden influir en el sistema. También se determinan los

requerimientos que se necesitaran para cada sistema, producto o servicio.
- Definir las necesidades de los interesados: se especifican las necesidades de
los interesados y dándoles distintas prioridades. Es probable que cada actor tenga
necesidades diferentes e incluso encontradas, por lo tanto el ES debe poner cada
necesidad cómo características de “alto nivel” del sistema que pueda ser entendido
por todas las partes y de ahí mediar entre aquellos que piensan diferente buscando
un concenso.
- Definir el Concepto de Operaciones (OpsCon) y otros conceptos: se definen
los distintos escenarios (ambiente, comportamiento, actividades del sistema)
operacionales durante todas las fases de la misión, lo que permite obtener nuevos
requerimientos.
- Transformar las necesidades en requisitos: las soluciones a cada necesidad se
traducen en requerimientos funcionales, de salud, seguridad, ambiente, etc.
También es necesario crear una base de datos con los requerimientos.
- Analizar los requerimientos de los interesados: se definen los criterios de
validación para los criterios, analizar la claridad y pertinencia de los requerimientos
y, en caso de haber problemas con alguno ya sea por ser irrealizable o no sea
práctico, se debe negociar su modificación.
- Administrar las necesidades y requerimientos de las partes: documentar y
realizar un seguimiento de las necesidades y requerimientos establecidos.
4.3 PROCESO DE DEFINICIÓN DE LOS REQUERIMIENTOS DEL SISTEMA
4.3.1 Propósito
Este proceso busca transformar el punto de vista de los interesados orientado al usuario a un
punto de vista técnico que solucione sus necesidades.
Los requerimientos del sistema son el fundamento para su definición y son la base de su
arquitectura, diseño, integración y validación. Cada requerimiento lleva un costo, por lo que
debe definirse la cantidad justa y necesaria y debe ser lo más precisa posible puesto que un
cambio en los mismos trae aparejado grandes costos especialmente en fases avanzadas del
proyecto.
Un buen requerimiento debe tener las siguientes características:
- Necesario
- No debe especificar ninguna implementación
- Debe ser completo y medible
- Debe ser singular (no vale una combinación de los mismos)
- Debe ser técnicamente alcanzable
- Debe ser verificable
- Debe tener un único formato dentro de la organización (esto facilita su lectura y
archivado).
20
4.3.2 Proceso
Actividades
- Preparar la definición de requerimientos del sistema: se define la arquitectura,

las interfaces, escenarios (comportamientos) y alcance del sistema.
- Definir los requerimientos del sistema: identificar y definir las funciones del
sistema requeridas. Definir los requerimientos de alto nivel funcionales, de calidad,
ambiente, etc y determinar el riego asociado a ellos. Este es un proceso iterativo
donde el SE debe encontrar un conjunto balanceado de requerimientos basados en
los objetivos de los usuarios. Normalmente implica llevar a cabo análisis de
performance, evaluación de limitaciones (estándares, entornos, consideraciones de
diseño) y análisis de costo-beneficio.
- Analizar los requerimientos del sistema: evaluar la integridad de los
requerimientos. Proveer información que garantice que los requerimientos
satisfacen las necesidades del interesado. Negociar cambios en los
requerimientos. Plantear criterios de validación.
- Administrar los requerimientos del sistema: establecer y mantener la
trazabilidad de los requerimientos durante todo el ciclo de vida de la misión.
4.4 PROCESO DE DEFINICIÓN DE LA ARQUITECTURA
4.4.1 Propósito
El proceso de definición de arquitectura consta de generar varias alternativas de arquitecturas
del sistema para luego elegir una que tenga características y propiedades que cumpla de la
mejor forma los requerimientos solicitados, el concepto de ciclo de vida y sea tecnológicamente
realizable.
Este proceso es iterativo y requiere de la participación tanto del ingeniero en sistemas cómo de
los demás arquitectos del sistema y los especialistas que sean necesarios.
21
4.4.2 Proceso
Actividades
- Preparar la definición de la arquitectura: identificar y analizar las condiciones del

mercado, la industria, los actores, las operaciones, las misiones, las leyes y cualquier
otro factor que pueda afectar al sistema. También se den tener en cuenta todos los
requerimientos planteados.
- Desarrollar los puntos de vista de las arquitecturas: en base a las necesidades de
los interesados, se establecen e identifican los distintos puntos de vista de las
arquitecturas.
- Desarrollar modelos de las arquitecturas candidatas: en base a una serie de
técnicas y herramientas de modelado establecidas. En base a estas se busca que
características de cada arquitectura (funciones, interfaces, flujo de datos, etc.) cumplen
con los requerimientos de más alta prioridad (las necesidades más importantes de los
interesados, características críticas de calidad, etc). A partir de ahí se crean modelos
pudiéndose ser lógicos o físicos (ver sección 9.1). Por último se verifican y se vlidan
estos modelos ya sea ejecutándolos o simulándolos.
- Relacionar la arquitectura con el diseño: determinar los elementos del sistema que
conformarán la arquitectura. Se deben establecer los principios que guiaran el diseño y
evolución del sistema. Se definen las interfaces entre estos elementos y los
requerimientos asociados a cada uno de ellos.
- Evaluar las arquitecturas candidatas: Empleando criterios de evaluación de
arquitecturas se evalúan los candidatos en base a los análisis, mediciones, y riesgos.
Finalmente se selecciona una arquitectura preferida.
- Administrar la arquitectura seleccionada: tomar nota de las distintas arquitecturas
propuestas y las decisiones tomadas. Controlar el mantenimiento y la evolución de la
arquitectura (elementos, características, modelos y vistas). Establecer los roles,
responsabilidades, autoridades y demás funciones. Finalmente se debe coordinar una
revisión con los interesados para que le den el visto bueno.
22
4.5 PROCESO DE DEFINICIÒN DEL DISEÑO
4.5.1 Propósito
Proveer un suficiente grado de detalle de los datos y la información acerca del sistema y sus
elementos para permitir una implementación consistente de la arquitectura definida en los
modelos y vistas de la arquitectura del sistema.
Las características de diseño incluyen las dimensiones, forma, material y la estructura de

procesamiento de los
4.5.2 Proceso
Actividades
- Preparar la definición del Diseño: identificar la tecnología necesaria para cumplir con
los objetivos de diseño para el sistema y sus componentes (se tiene en cuenta la
obsolescencia de la tecnología, su reemplazo o posible evolución).
- Establecer las características de diseño relativo a cada elemento del sistema:
Asociar los requerimientos a cada elemento del sistema.
Definir las características de diseño para las entidades de la arquitectura y asegurarse
que es factible.
Definir las interfaces internas y externas
- Evaluar alternativas para obtener los elementos del sistema: Se identifican y
evalúan los elementos existentes implementados (COTs, reuso, no desarrollados y
nuevos) y se selecciona el mas apropiado.
- Gestión del diseño: Se gestiona el mantenimiento y la evolución del diseño.
23
4.6 PROCESO DE ANÁLISIS DEL SISTEMA
4.6.1 Propósito
Proveer una base rigurosa de datos e información (análisis de costos, riesgo, factibilidad,
efectividad y otras características críticas) para tener un entendimiento técnico que permita
tomar decisiones a lo largo del ciclo de vida.
4.6.2 Proceso
Actividades
- Preparar el análisis del sistema: Se define el alcance, el tipo, objetivos y nivel de

exactitud de los análisis de los requerimientos y sus niveles de importancia para las
partes interesadas.
Además se definen o eligen los criterios de evaluación (condiciones operacionales, de
contexto, de performance, tipo de riesgo y costos)
Se determinan los elementos a analizar
Se programan los análisis de acuerdo a la disponibilidad de modelos de ingeniería por
ejemplo
Se documenta la estrategia de análisis del sistema correspondiente.
- Realizar el análisis del sistema: Se obtienen los datos y las entradas necesarias para
el análisis, resaltando cualquier suposición. Las entradas (input) pueden incluir
modelos, tales como:
o Modelos Físicos
o Modelos de Representación (simulan el comportamiento de un sistema o
elemento del sistema)
o Modelos Analíticos (determinísticos o estocasticos) que establecen valores que
se aproximan a la operación real
- Gestionar el análisis del sistema: Se resaltan los resultados del análisis o reportes
utilizando el proceso de gestión de la configuraciòn
Se mantiene un historial de ingeniería de la evolución del sistema.
- Gestión del diseño: Se gestiona el mantenimiento y la evolución del diseño.
24
4.7 PROCESO DE IMPLEMENTACIÓN
4.7.1 Propósito
El propósito del proceso de Implementación es realizar un elemento específico de sistema.
4.7.2 Proceso
Actividades:
• Prepararse para la implementación.

- Definir procedimientos de fabricación / codificación, herramientas y equipo que se utilizará,
tolerancias y criterios de implementación.
- Obtener de las partes interesadas, los desarrolladores y los compañeros de equipo las
restricciones impuestas por la tecnología, la estrategia empleada, en la definición de los
requisitos, la arquitectura y el diseño.
- Documentar el plan para adquirir o ganar acceso a los recursos necesarios durante la
implementación. La planificación incluye la identificación de requisitos e interfaces para la
habilitación del sistema.
• Realizar la implementación.
- Desarrollo de capacitación a los usuarios. Documentación sobre el procedimiento correcto y
seguro para operar y mantener ese elemento, ya sea como un elemento final independiente o
como parte de un sistema más grande.
- Complete el producto detallado, el proceso, las especificaciones del material y análisis
correspondientes. Registro de materiales peligrosos, si corresponde.
- Asegurar la realización de los elementos del sistema por el producto detallado, el proceso y la
especificación del material y producir evidencia documentada del cumplimiento de la
implementación.
- Determinar los requisitos de embalaje y almacenamiento para el elemento del sistema y
garantizar el inicio del embalaje y / o almacenamiento, en el tiempo apropiado.
4.8 PROCESO DE INTEGRACIÓN
25
4.8.1 Propósito
El propósito del proceso de Integración es sintetizar un conjunto de elementos del sistema en

un sistema realizado (producto o servicio) que satisface los requisitos del sistema, arquitectura
y Diseño.
4.8.2 Proceso
Actividades:
• Prepárate para la integración.
- Definir puntos de control críticos para proporcionar seguridad del correcto funcionamiento de
las interfaces y funciones de los elementos del sistema.
- Establecer la estrategia de integración que minimice el tiempo de integración, costos y
riesgos.
- Identificar las restricciones de integración en el SOI, que surgen de la estrategia de
integración, para ser incorporadas en los requisitos del sistema, la arquitectura, y diseño.
- La adquisición de los habilitadores se puede hacer a través de varias formas, como alquiler,
adquisición, desarrollo, reutilización y subcontratación.
• Realizar integración: integrar el sistema sucesivamente y las configuraciones de elementos
hasta que el sistema completo sea sintetizado.
- Reúna los elementos del sistema verificados y validados para formar el agregado incremental
usando los procedimientos de ensamblaje definidos.
- Invocar los procesos de V y V del sistema, según sea necesario, a verificar la correcta
implementación de las características de la arquitectura y propiedades de diseño y para
verificar que los elementos individuales del sistema proporcionan las funciones previstas.
• Gestionar resultados de integración.
- Identificar y registrar los resultados de la integración. Mantener la trazabilidad bidireccional de
la actualización de elementos integrados del sistema con la actualización de la arquitectura,
diseño y sistema del sistema y requisitos de interfaz. Mantener los registros, incluidas las
actualizaciones de configuración, por política de la organización.
- Registrar anomalías observadas durante el proceso de integración (identificar acciones
correctivas o mejoras), y resolverlos usando el proceso de garantía de calidad.
26
4.9 PROCESO DE VERIFICACIÓN
4.9.1 Propósito
El propósito del proceso de verificación es proporcionar evidencia objetiva de que un elemento

del sistema o sistema cumple sus requisitos y características especificados.
4.9.2 Proceso
Actividades:
• Prepararse para la verificación.
- Desarrollar una estrategia que priorice las acciones de verificación para minimizar costos y
riesgos mientras maximiza la cobertura operacional del comportamiento del sistema: Establecer
los objetos de verificación, restricciones, planes para métodos o técnicas que serán aplicadas
en cada verificación, establecer un ambiente de verificación.
- Desarrollar los procedimientos de verificación que apoyan las acciones de verificación.
- Identificar restricciones de verificación en el sistema o elementos del sistema, derivados de la
estrategia de verificación que se relaciona con los requisitos específicos del sistema, elementos
arquitectónicos, o elementos de diseño.
- Asegurar los sistemas habilitantes necesarios, los productos o servicios requeridos para la
verificación, las acciones estén disponibles, cuando sea necesario. La planificación incluye la
identificación de requisitos e interfaces para los habilitadores.
• Realizar la verificación.
- Implementar el plan de verificación desarrollado en la subsección anterior. Ese plan incluye
detalles y descripciones para las acciones de verificación seleccionadas:
° Artículo a verificar
° Resultados esperados y criterios de éxito
° Método o técnica de verificación seleccionada
° Los datos necesarios
° Los sistemas, productos o servicios habilitantes correspondientes
- Usando los procedimientos de verificación, ejecute las acciones de verificación y registrar los
resultados.
- Analizar los resultados de verificación contra cualquier expectativa establecida y criterios de
éxito para determinar si el elemento que está siendo verificado indica conformidad.
27
• Administrar los resultados de la verificación.
- Identificar y registrar resultados de verificación y ingrese los datos en la matriz de verificación

de requisitos y Trazabilidad (RVTM). Mantener los registros por política organizacional.
- Registrar las anomalías observadas durante la verificación procesar, analizar y resolver las
anomalías (acciones correctivas o mejoras) usando el proceso de garantía de calidad.
- Establecer y mantener la trazabilidad bidireccional de los elementos del sistema verificado
con la arquitectura del sistema arquitectura, diseño y sistema y requisitos de interfaz que son
necesarios para la verificación.
- Proporcionar información de referencia para la configuración de administración.
- Actualizar la estrategia de verificación y el cronograma de acuerdo con el progreso del
proyecto; en particular, las acciones de verificación planificadas pueden ser redefinidas o
reprogramadas según sea necesario.
- Coordinar las actividades de verificación con el gerente de proyecto (por ejemplo, para la
programación, adquisición de habilitadores, contratación de personal calificado y recursos), los
arquitectos o diseñadores (por ejemplo, para errores, defectos, informes de no conformidad), y
administrador de configuración (por ejemplo, para versiones de elementos enviados, requisitos,
arquitectura y diseño) líneas de base, habilitadores, procedimientos de verificación).
4.10 Proceso de Transición
4.10.1 descripción general

4.10.1.1 Propósito
Según lo establecido en ISO / IEC / IEEE 15288,
[6.4.10.1] El propósito del proceso de transición es establecer la capacidad de un sistema para

proporcionar servicios especificados por los requisitos de las partes interesadas en el entorno
operativo.
En última instancia, el proceso de transición permite la transferencia de la custodia del sistema

y la responsabilidad del soporte del sistema de una entidad organizacional a otra. Esto incluye,
pero no se limita a, la transferencia de la custodia del equipo de desarrollo a las organizaciones
que posteriormente operarán y apoyarán el sistema. La conclusión exitosa del proceso de
transición normalmente marca el comienzo de la etapa de utilización del SOI.
4.10.1.2 Descripción
El proceso de transición instala un sistema verificado en el entorno operacional junto con los
sistemas, productos o servicios habilitantes pertinentes, como los sistemas de capacitación de
operadores, tal como se definen en el acuerdo. Usando resultados exitosos del proceso de
verificación, el adquirente acepta que el sistema reúne los requisitos del sistema especificados
en el entorno operativo previsto antes de permitir un cambio en el control, propiedad y / o
custodia. Si bien este es un proceso relativamente corto, debe planificarse cuidadosamente
para evitar sorpresas y recriminaciones en ambos lados del acuerdo. Además, los planes de
transición deben ser rastreados y monitoreados para asegurar que todas las actividades se
completen a satisfacción de ambas partes, incluida la resolución de cualquier problema que
surja durante la transición. La Figura 4.16 es el diagrama de IPO para el proceso de transición.
4.10.1.3 Entradas / Salidas

Las entradas y salidas para el proceso de transición se enumeran en la Figura 4.16. Las descripciones de
cada entrada y salida se proporcionan en el Apéndice E.
4.10.1.4 Actividades de proceso
28
El proceso de transición incluye las siguientes actividades:
• Preparación para la transición.

- Plan para la transición del sistema. La estrategia debe incluir capacitación de operadores, apoyo
logístico, estrategia de entrega y estrategia de resolución / resolución de problemas.
- Procedimientos de instalación.
- Disponibilidad de los sistemas, productos o servicios habilitantes necesarios para la
transición, cuando sea necesario.
• Realizar la transición.
- Usando los procedimientos de instalación, instale el sistema.
- Capacitar a los usuarios en el uso adecuado del sistema.
- Recibir la confirmación final de que el sistema instalado puede proporcionar las funciones
requeridas y puede ser sostenido por los sistemas y servicios habilitantes.
- Después de la demostración de la funcionalidad en el sitio operacional y de cualquier revisión
para la preparación operacional, el sistema puede ponerse en servicio.
• Gestionar los resultados de la transición.

- Los incidentes y problemas posteriores a la implementación se capturan y pueden llevar a
acciones correctivas o cambios a los requisitos. El proceso de aseguramiento de calidad se usa
para el incidente y la resolución del problema que se informa durante la ejecución del proceso
de transición.
- Registrar las anomalías observadas durante el proceso de transición. Estos proporcionan
conocimiento de los resultados, la información necesaria para abordar anomalías y un registro
histórico. Las anomalías pueden derivarse de la estrategia de transición, soportando sistemas
de habilitación, interfaces, etc. La evaluación del proyecto y el proceso de control se utilizan
para analizar las anomalías y determinar qué acción, si es que alguna, se necesita.
- Mantener la trazabilidad bidireccional de los elementos del sistema transicionado con la
estrategia de transición, la arquitectura del sistema, el diseño y los requisitos del sistema.
- Proporcionar información de referencia para la gestión de la configuración.
Enfoques y consejos comunes:

• Cuando las actividades de aceptación no pueden llevarse a cabo dentro del entorno
operativo, se selecciona una configuración regional representativa.
• Este proceso depende en gran medida de la garantía de calidad y la documentación de
gestión de la configuración.
29
Figure 4.16 IPO diagram for the transition process. InCOSE SEh original figure created by Shortell and
Walden. Usage per the InCOSE notices page. All other rights reserved.
4.11 Proceso de validación
4.11.1 descripción general

4.11.1.1 Propósito
Según lo establecido en ISO / IEC / IEEE 15288,
[6.4.11.1] El propósito del proceso de Validación es proporcionar evidencia objetiva de que el

sistema, cuando está en uso, cumple sus objetivos comerciales o de misión y los requisitos de
los interesados, logrando su uso previsto en el entorno operacional previsto.
4.11.1.2 Descripción
El proceso de validación se puede aplicar a cualquier elemento del sistema o elemento de

ingeniería del sistema o su definición que se haya definido o realizado (p. Ej., Validación de un
requisito de partes interesadas, un requisito del sistema, una función, un flujo de entrada /
salida, un elemento del sistema , una interfaz, una propiedad de diseño, un agregado de
integración, un procedimiento de validación). Por lo tanto, el proceso de validación se realiza
para ayudar a garantizar que el sistema o cualquier elemento del sistema satisfaga las
necesidades de sus partes interesadas.
El proceso de validación trabaja estrechamente con otros procesos del ciclo de vida. Por
ejemplo, el proceso de análisis de negocios o misiones establece una capacidad operacional
específica. La capacidad operativa (por ejemplo, el perfil de la misión o el negocio y los
escenarios operativos) se transforma mediante el proceso de definición de requisitos y
necesidades de las partes interesadas en necesidades y requisitos de las partes interesadas.
La Figura 4.17 es el diagrama de IPO para el proceso de validación.
4.11.1.3 Entradas / Salidas
Las entradas y salidas para el proceso de validación se enumeran en la Figura 4.17. Las
descripciones de cada entrada y salida se proporcionan en el Apéndice E.
4.11.1.4 Actividades de proceso
El proceso de validación incluye las siguientes actividades:

• Prepárese para la validación.
- Establecer la estrategia de validación, que a menudo es parte de un plan de validación, que
optimiza el número y tipo de acciones de validación mientras se minimizan los costos y riesgos:
30
° Identificar las partes interesadas que participarán en las actividades de validación y definir sus
roles y responsabilidades. Esto puede incluir al adquirente, el proveedor y un representante
externo.
° El alcance del plan de validación depende de la etapa del ciclo de vida y del progreso dentro
de ella.
° Establecer una lista de restricciones de validación que deben considerarse.
° Con la consideración adecuada de las limitaciones, seleccione el enfoque de validación
adecuado que se aplicará, como inspección, análisis,
Figure 4.17 IPO diagram for the validation process. InCOSE SEh original figure created by Shortell and
Walden. Usage per the InCOSE notices page. All other rights reserved.
demostración o prueba, dependiendo de la etapa del ciclo de vida. Identifique los habilitadores
necesarios.
° Determinar si hay vacíos de validación y que las acciones de validación resultantes proporcionarán un
nivel aceptable de confianza de que el elemento del sistema o sistema satisfará las necesidades
identificadas.
° Asegurar una programación adecuada a través del proceso de planificación del proyecto para cumplir
con los requisitos para la ejecución de las acciones de validación en los pasos del proyecto
correspondientes.
° Definir la configuración de los elementos enviados a las acciones de validación.
- Identificar las restricciones de validación en el sistema, derivadas de la estrategia de validación, para

ser incorporadas en los requisitos de las partes interesadas.
- Asegúrese de que estén disponibles los sistemas, productos o servicios habilitantes necesarios para las
acciones de validación, cuando sea necesario.
• Realizar la validación.
- Desarrollar los procedimientos de validación que respaldan las acciones de validación.
- Asegurar la disponibilidad para llevar a cabo la validación: disponibilidad y estado de configuración del
sistema / elemento, la disponibilidad de habilitadores de validación, personal calificado u operadores,
recursos, etc.
- Llevar a cabo acciones de validación de acuerdo con los procedimientos. Esto debería incluir realizar las
acciones en el entorno operacional o lo más cerca posible. Durante la realización de las acciones de
validación, registre los resultados de las acciones, a medida que se realizan.
31
• Gestionar resultados de validación.

- Identificar y registrar resultados de validación e ingresar datos en el informe de validación. Mantener
los registros según la política de la organización.
- Registrar las anomalías observadas durante el proceso de validación, y analizar y resolver las anomalías
utilizando el proceso de garantía de calidad (ver Sección 5.8).
° Asegurar que los resultados y las anomalías y / o no conformidades se analizan utilizando el proceso de
evaluación y control del proyecto.
° Comparar los resultados obtenidos con los resultados esperados; deducir el grado de conformidad del
elemento presentado (es decir, proporciona los servicios esperados por el interesado); decidir si el
grado de conformidad es aceptable.
La resolución del problema se maneja a través de los procesos de control de calidad y evaluación y
control de proyectos. Los cambios en la definición del elemento del sistema o del sistema (es decir,
requisitos, arquitectura, diseño o interfaces) y los artefactos de ingeniería asociados se realizan dentro
de otros procesos técnicos.
- Obtener la aceptación del adquirente (u otras partes interesadas autorizadas) de los resultados de la
validación.
- Mantener la trazabilidad bidireccional de los elementos validados del sistema con la estrategia de
validación, el análisis del negocio / misión, los requisitos de las partes interesadas, la arquitectura del
sistema, el diseño y los requisitos del sistema.
- Proporcionar información de referencia para la gestión de la configuración.
Enfoques y consejos comunes:
• Los métodos de validación durante el proceso de análisis de negocio y misión incluyen la evaluación de
OpsCon a través de escenarios operacionales que ejercitan todos los modos operativos del sistema y
que demuestran el rendimiento a nivel del sistema durante todo el régimen operativo. Los arquitectos y
diseñadores usan los resultados de esta actividad para pronosticar el éxito en el cumplimiento de las
expectativas de los usuarios y el adquirente, así como proporcionar retroalimentación para identificar y
corregir las deficiencias de desempeño antes de la implementación (Engel, 2010).
• Se recomienda comenzar la redacción del plan de validación tan pronto como se conozcan los
primeros OpsCon y los escenarios y los requisitos de las partes interesadas.
• La validación se aplica al sistema operativo, pero es más efectiva si también se aplica antes mediante
análisis, simulación, emulación, etc. de las características operacionales anticipadas.
• Un resultado clave de la validación es la seguridad provista por los loci de los límites dinámicos e
integridad del sistema. Estos sobres brindan un conocimiento procesable para que los usuarios
determinen la idoneidad del sistema, la eficacia anticipada, la capacidad de supervivencia y el
reacondicionamiento.
• La validación también revela los efectos que el SOI puede tener en los sistemas de garantía,
habilitación o interoperación. Las acciones y el análisis de validación deben incluir estas interacciones
del sistema en el alcance.
• Involucrar a la más amplia gama de partes interesadas con la validación. A menudo, los usuarios finales
y otras partes interesadas relevantes participan en las actividades de validación.
• Si es posible, involucre a los usuarios / operadores con validación. La validación a menudo implica
volver directamente a los usuarios para que realicen algún tipo de prueba de aceptación bajo sus
propias condiciones locales.
4.11.2 Elaboración
4.11.2.1 Concepto de acción de validación
Una acción de validación describe qué debe validarse (por ejemplo, un escenario operacional, un
requisito o un conjunto de requisitos como referencia), sobre qué elemento (por ejemplo, requisito,
función, interfaz, elemento del sistema, sistema), el resultado esperado (deducido de la referencia), la
técnica de validación a aplicar (por ejemplo, inspección, análisis, demostración, prueba) y en qué nivel
de la jerarquía del sistema (p. ej., SOI, elemento del sistema de nivel intermedio, nivel hoja) elemento
del sistema).
32
La definición de una acción de validación aplicada a un elemento de ingeniería (por ejemplo, requisito
de parte interesada, sistema, requisito, función, interfaz, elemento del sistema, procedimiento,
documento) incluye la identificación del elemento sobre el que se realizará la acción de validación, la
referencia utilizada para definir el resultado esperado y la técnica de validación adecuada.
La realización de una acción de validación en el elemento presentado proporciona un resultado
obtenido que se compara con el resultado esperado. La comparación permite que el proyecto juzgue la
aceptabilidad del elemento con respecto a la relevancia en el contexto de uso (ver Fig. 4.18).
Ejemplos de acciones de validación:
• Validación de un requisito: para asegurarse de que su contenido esté justificado y sea relevante para
las necesidades o expectativas de los interesados.
• Validación de un artefacto de ingeniería (arquitectura, diseño, etc.): para asegurarse de que su
contenido esté justificado y sea relevante para las necesidades o expectativas de los interesados y
contribuye a lograr el perfil de misión o negocio y los escenarios operativos.
• Validación de un sistema (producto, servicio o empresa): para demostrar que el producto, servicio o
empresa satisface las necesidades de sus partes interesadas, su perfil de misión o negocio y los
escenarios operativos.
4.11.2.2 Técnicas de validación

Las técnicas de validación son las mismas que las utilizadas para la verificación (ver Sección 4.9.2.2),
pero los propósitos son diferentes; la verificación se usa para mostrar el cumplimiento de los requisitos
especificados del sistema y para detectar errores / defectos / fallas, mientras que la validación es para
demostrar la satisfacción de la capacidad operativa deseada mediante la demostración de escenarios
operativos y requisitos de partes interesadas.
Se puede utilizar una matriz de trazabilidad de requisitos y validación para registrar datos como la lista
de acciones de validación, el método / técnica de validación seleccionada para validar la
implementación de cada elemento de ingeniería (en particular, escenarios operacionales y requisitos de
partes interesadas), los resultados esperados y los resultados obtenidos cuando una acción de
validación ha sido realizada.
33
Figure 4.18 Definition and usage of a validation action. Reprinted with permission from Alain Faisandier.
All other rights reserved.
4.11.2.3 Validación, validación operacional, aceptación y certificación
Validación y validación operacional
La validación se refiere al sistema global visto como un todo y se basa en la totalidad de los requisitos
(requisitos del sistema, requisitos de las partes interesadas). Se obtiene gradualmente a lo largo de la
etapa de desarrollo al buscar varias formas no exclusivas:
• Resultados acumulados de las acciones de V & V proporcionados por la aplicación de los procesos
correspondientes a cada elemento de ingeniería
• Realización de acciones de validación final en el sistema integrado completo en un entorno industrial
(lo más cerca posible del entorno operativo futuro)
• Realización de acciones de validación operativas en todo el sistema en su entorno operativo (contexto
de uso)
El objetivo es validar por completo la capacidad del sistema para cumplir con todos los requisitos antes
de las etapas de producción y utilización. Los problemas descubiertos en estas etapas son muy costosos
34
de corregir. Como tal, el descubrimiento temprano de las desviaciones de los requisitos reduce el riesgo
general del proyecto y ayuda al proyecto a entregar un sistema exitoso y de bajo costo.
Aceptación
La aceptación es una actividad realizada antes de la transición, de modo que el adquirente puede decidir
que el sistema está listo para cambiar la propiedad del proveedor al adquirente.
Certificación
La certificación es una garantía escrita de que el producto o artículo ha sido desarrollado y puede
realizar sus funciones asignadas, de acuerdo con las normas legales o industriales (por ejemplo, para
aeronaves).
la certificación generalmente es realizada por autoridades externas, sin una dirección de cómo se deben
verificar los requisitos. Por ejemplo, este método se utiliza para dispositivos electrónicos a través de la
certificación Conformité Européenne (CE) en Europa y la certificación de los laboratorios Underwriters
(Ul) en los Estados Unidos y Canadá.
Preparación para el uso

Como parte del análisis de los resultados de validación, el equipo del proyecto debe estar preparado
para la evaluación del uso. Esto puede ocurrir muchas veces en el ciclo de vida, incluida la primera
entrega del artículo, la finalización de la producción (si se produce más de un sistema) y las siguientes
acciones de mantenimiento. En el campo, particularmente después del mantenimiento, es necesario
establecer si el sistema está listo para usar.
Calificación
La calificación del sistema requiere que todas las acciones de V & V se hayan realizado con éxito. Estas
acciones de V & V cubren no solo la propia SOI sino también todas las interfaces con su entorno (por
ejemplo, para un sistema espacial, la validación de la interfaz entre el segmento espacial y segmento de
tierra). El proceso de calificación debe demostrar que las características o propiedades del sistema
realizado, incluidos los márgenes, cumplen con los requisitos del sistema y / o los requisitos de los
interesados. La calificación se concluye con una revisión de aceptación y / o una revisión de preparación
operacional.
Como ilustración de esto, para un sistema espacial, el primer paso de la calificación está cubierto por el
primer lanzamiento o el primer vuelo. Este primer vuelo debe ser evaluado mediante una revisión de
preparación de vuelo que verificará que los segmentos de vuelo y de tierra, incluidos todos los sistemas
de apoyo, como los sistemas de seguimiento, los sistemas de comunicación y los sistemas de seguridad,
estén listos para su lanzamiento. Un lanzamiento exitoso participa en el proceso de calificación, pero la
calificación final del sistema se logra solo después de pruebas en órbita para una nave espacial o incluso
varios vuelos para un lanzador con el fin de cubrir las diferentes misiones para las que se ha
desarrollado el sistema.
35
4.11.2.4 Nivel de validación por nivel
Generalmente, el SOI se ha descompuesto durante la definición de arquitectura en un conjunto de

capas de sistemas; por lo tanto, todos los elementos del sistema y el sistema se validan y posiblemente
se corrigen antes de integrarse en el sistema principal del nivel superior, como se muestra en la Figura
4.19. En esta figura, cada vez que se utiliza el término validar significa que se invoca el proceso de
validación correspondiente.
Según sea necesario, los sistemas y los elementos del sistema se integran parcialmente en subconjuntos
(agregados) con el fin de limitar el número de propiedades a ser validadas en un solo paso.
4.12 PROCESO DE OPERACIÓN
4.12.1 Propósito
El propósito del Proceso de operación es usar el sistema para entregar sus servicios. Este
proceso es a menudo ejecutado simultaneamente con los procesos de mantenimiento.
El proceso de operación mantiene los servicios del sistema preparados para su operación,
suministrando personal para operar al sistema, operador de monitoreo de performance del
sistema, cuándo el sistema reemplaza a uno existente, este deberá necesariamente manejar la
migración entre los sistemas de tal manera de que los usuarios/clientes no experimenten una
baja en los servicios.
36
Si la performance cae fuera de los parámetros aceptables, esto puede indicar la necesidad de
acciones correctivas en concordancia con soporte de concepto y algunos acuerdos asociados.
Cuando el sistema o alguno de sus elementos alcanza el final de su ciclo de vida entonces el
satélite debe entrar al proceso de disposición.
Proceso de operación
4.12.1.4 Actividades del proceso

● Disponer para la operación
- El plan para la operación, incluyendo el desarrollo de la estrategia
● Establecer disponibilidad de equipos, servicios, y personal y seguimiento de
performance del sistema.
● Verificar las arquitecturas de personal y las facilidades
● Implementar la OpsCon y estrategias ambientales.
● Revisar las mediciones de performance operacional, umbrales, y criterios
● Verificar todo el personal que trabajó en el seguimiento de Safety del sistema.
- Realimentación de algunas restricciones de operación en la definición de
requerimientos del sistema, o diseño de proceso de diseño.
- Asegurar que los sistemas de habilitación necesarios, productos, o servicios requeridos
para la operación están disponibles cuando lo necesiten. La planificación incluye la
identificación de requerimientos e interfaces para los habilitadores. Las adquisiciones
de los habilitadores pueden ser a través de varios caminos como ser rentado,
comprado, desarrollado, reusó, y subcontratado. Un habilitador puede ser un completo
sistema de habilitación desarrollado como un proyecto separado del SOI.
- Identificar las capacidades del operador y formar operadores para operar el sistema.
● Ejecutar la operación
- Operar el sistema acorde al OpsCon
- Sistema de seguimiento y reporte de performance para la disponibilidad operacional.
Esto incluye la operación del sistema de una manera segura y realizar un análisis
operacional para determinar incumplimiento del sistema.
37
- Garantizar, cuando las condiciones de operación sean anormales, acciones de

contingencia planificadas. Realizar un sistema de operación de contingencia, si es
necesario.
● Gestión de resultados de las operaciones
- documentar los resultados de las operaciones.
- Registrar anomalías observadas durante el proceso de operación, y analizar y
solucionar la anomalía (acciones correctivas o mejoras) usando el proceso
aseguramiento de calidad. Se deberá Implementar de procesos para restaurar
operaciones para asegurar el estado. Mantener un seguimiento bidireccional de las
operaciones elementales con la operación estratégica, de análisis de negocio/ misión,
ConOps, OpsCon, y requerimientos de usuarios/clientes.
● Soporte al consumidor
- Llevar las tareas necesarias para dar dirección a las consultas del consumidor.
4.12.2 Elaboración
4.12.2.1 Sistemas de habilitación de operación
El proceso de operación incluye otros sistemas de habilitación que requieren ser diferenciados
de otros procesos.
● Ambiente operacional –Las circunstancias del entorno y potenciales efectos sobre las
cosas operativas. Ejemplo el equipamiento electrónico o mecánico puede ser afectado
por las altas temperaturas, vibraciones, polvo etc.
● Sistemas de seguimiento –Proveer operadores con los conocimientos y capacidades
requeridas para la operación apropiada de sistema.
● Dato técnico -Procedimientos, guías, y listas de control necesarias para la operación
apropiada del sistema, incluyendo pre-requisitos de operación, procedimientos para
activación y control de salida del sistema, procedimientos de operación, de monitoreo
de performance del sistema, para resolución de problemas, y cerrado ante la caída
del sistema.
● Facilidades e infraestructura –facilidades (Ej edificios, aeródromos, puertos,
caminos) y infraestructura (Ej Servicios IT, gasolina, agua, servicios eléctricos )
requeridos para la operación del sistema.
● Ingeniería sustentable- Monitor de performance del sistema, análisis de fallas, y
procesos de acciones correctivas para sustentar las capacidades operacionales
requeridas.
● Gestión y planificación del mantenimiento- según las reglas para minimizar tiempo
muertos en el sistema, una planificación y/o mantenimiento preventivo es llevado a
cabo para mantener las operaciones del sistema. El sistema de mantenimiento
responde a reportes de problemas del operador, mantenimiento correctivo,
recuperación del sistema para operaciones.
4.13 PROCESO DE MANTENIMIENTO
4.13.1 Propósito
Es mantener la capacidad de el sistema para proveer servicios.
4.13.1.1 Descripcion El mantenimiento incluye las actividades para proveer soporte de

operaciones ,logistica y gestion de material.Basado en la realimentación de monitoreos del
ambiente operacional, los problemas son identificados,y las acciones preventivas o correctivas
se toman para restaurar la capacidad total del sistema.Este proceso contribuye a los procesos
38
de definición de requerimientos de sistema,de arquitectura,de diseño cuando se considera las

restricciones impuestas en las siguientes etapas del ciclo de vida estan usadas para influir en
los requerimientos del sistema .
Proceso de Mantenimiento
4.13.1.4 Actividades del Proceso

● Preparar para el mantenimiento
- Plan para mantenimiento,incluyendo el desarrollo de la estrategia:
● Mantener el servicio a través del ciclo vida para reunir los
requerimientos del consumidor y satisfacerlo.Se debe definir los tipos
de mantenimientos (preventivo correctivo,modificación) y los niveles de
mantenimiento(operador,in situ,factory)
● Hay varios tipos de acciones de mantenimientos para minimizar el
tiempo inactivo operacional , como ser los mantenimientos correctivo
(direccionado de fallas o problemas),adaptativo(cambios de dirección
necesaria para acomodar la evolución del sistema),perfectivo(mejorado
de direccionamiento) y el preventivo estructural( rutinas de
direccionamiento para prevenir fallas)
● el enfoque de direccionamiento logístico necesario a través del ciclo de
vida.
- Enfoque para gestionar partes de repuesto o elementos de
sistema (Ej. número,tipo,
almacenamiento,localización,duration,condiciones,frec
uencia de renovación) . El análisis incluye requerimientos y
planificación para empaquetado,entregado,almacenado y
transporte (PHS&T)
- Enfoque antifalsificación (Ej prevención de falsificación de
elemento,especialmente partes,en la cadena de suministro)
39
- Identificar o definir fuentes de datos técnicos y seguimientos

necesarios para soporte de mantenimiento.
- Identificar o definir las habilidades,formación,calificación ,y
número de personal para el mantenimiento.Considera algún
requerimiento regulatorio que maneje las necesidades de
habilidades específicas, tal como safety o seguridad.
- Realimentación alguna restricción del sistema en el sistema o elementos del
sistema para la definición de requerimientos, de la arquitectura o proceso de
definición de diseño.
- Usar el proceso de análisis de sistema para soporte de alguna necesidad de
compromiso de la estrategia de mantenimiento y enfoque para asegurar la
asequibilidad,facilidad,compatibilidad,y sustentabilidad del mantenimiento del
sistema.
● Asegurar que los sistemas de habilitación necesarios,productos, o
servicios requeridos para el mantenimiento estén disponibles cuando lo
requieran.La planificacion incluye la identificicacion de requerimientos
e interfaces para los habilitadores.La adquisicion de los habilitadores
puede ser a través de varios caminos como ser
rentados,comprados,desarrollados ,reuso ,y subcontratados.Un
habilitador puede ser desarrollado como un proyecto aparte del SOI.
● Asignar personal formado,cualificado para ser mantenedores.
● Ejecución del mantenimiento
- Desarrollo del proceso de mantenimiento para mantenimiento preventivo y
correctivo.
- Identificar ,guardar, y resolver anomalías del sistema.
- Restaurar la operación del sistema después de fallas.
- Plan para futuros mantenimientos para revisar y analizar los reportes de
anomalías.
- Inicializar análisis y acciones correctivas para remediar errores de diseños
previos no detectados
- Por la identificación de la estructura ,la realización de las acciones de
mantenimiento preventivo usando procedimientos de mantenimiento definidos.
- Determinar las necesidades para la adaptativa o perfectiva.
● Ejecucion de soporte logístico.
- Realizar acciones logísticas de adquisición - incluir estudios de compromiso y
análisis para determinar el costo principal efectivo para soportar al sistema a lo
largo del ciclo de vida.Diseños que consideren las características que impactan
la confiabilidad y mantenibilidad de los servicios del sistema contrastados con
la asequibilidad de otras opciones de soporte incluyendo el uso de
repuestos.Las consideraciones de diseño son a menudo restringidas por los
requerimientos de disponibilidad,el impacto la gestión de la cadena de
suministro,restricciones de mano de obra y asequibilidad del sistema.Los
planes logísticos de adquisición y desarrollo de estrategias para el ciclo de vida
del sistema compatibles con la definición de los requerimientos del sistema.
- Realizar acciones logísticas operacionales - La logística operacional está
sincronizada al SOI y a los sistemas habilitadores en la vida operacional para
asegurar el envío efectivo y eficiente de las capacidades del sistema.Habilita
al sistema para lograr las revisiones operacionales requeridas.Las acciones
incluyen dotación de personal,gestión de mantenimiento ,suministro de
soporte,equipamiento de soporte, datos técnicos necesarios ,formación de
soporte,ingeniería sustentable,recursos de cómputo y facilidades.Provee una
rica fuente de datos relacionados a la performance operacional del
sistema.Estos datos deberán ser usados para soportar los análisis de
40
tendencia y proveer un lazo directo de realimentación sobre el sistema efectivo

y eficiente viendo la satisfacción del cliente.
● Gestión de resultados de mantenimiento y logística
- Documentar los resultados de los procesos de mantenimiento.
- Guardar las anomalías observadas durante el proceso de mantenimiento, y
analizar y resolver las anomalías (acciones correctivas ) usando el proceso de
aseguramiento de calidad.Identificar y guardar los estados de las acciones de
mantenimiento y logística.
- Mantener el seguimiento bidireccional de las acciones de mantenimiento
- Obtener realimentación desde los consumidores para entender el nivel de
satisfacción con el mantenimiento y el soporte de logística.
4.13.2 Elaboración
El término Mantenimiento es a menudo utilizado para referirse a una fase en la cual el sistema
ya está operando y las actividad primaria es sustentar las capacidad del
sistema,mejoras,actualizaciones y modernizaciones.En este contexto el objetivo está en
diseñar el sistema desde el inicio para permitir el mantenimiento del valor durante todo el ciclo
de vida del sistema ,de modo de promover una valor sustentable.Sin embargo los costos de
mantenimiento y operaciones significan un porcentaje importante del total LCC,el
mantenimiento es una parte importante de la definición del sistema ,a menudo asociado a la
ingeniera logística,deposición,y análisis de impactos ambientales.
El mantenimiento ayuda a asegurar que el sistema continúe satisfactoriamente su objetivo en el

tiempo de vida destinado.Tiempo en el cual ,las expectativas aumentarian ,los ambientes en
que el sistema es operado cambiarían,la tecnología revolucionaria y los elementos del sistema
podrían perder el soporte y necesitarian ser reemplazados. Un ejemplo de esto el el Cots del
ambiente informático de escritorio.
4.13.2.1 Concepto de mantenimento
El concepto de mantenimiento es un importante documento conceptual del ciclo de vida.

● Tipos de mantenimientos
- Mantenimiento correctivo- procesos y procedimientos para restaurar los
servicios del sistema a una operación normal (remover y reemplazar
hardware,recargar software,aplicar parches de software). incluye
procedimientos de test post-mantenimiento para verificar que el sistema esté
listo para operar.
- Mantenimiento preventivo- Proceso y procedimiento para programar/rutinas
acciones de mantenimiento necesarios para mantener el performance
operacional óptimo del sistema.Ej cambiar filtros,inspecciones visuales .
- Modificaciones de sistema- Procesos y procedimientos destinados a aumentar
la vida útil del sistema o para proveer nuevas capacidades al sistema.
● Niveles de mantenimiento / reparación
- mantenimiento Usuario/operador -Algunas rutinas (ej cambio de de filtro) y
simples tareas correctivas( ej reseteo de software) de mantenimiento pueden
ser llevadas a cabo por los operadores del sistema o usuarios.
- Mantenimiento y reparación IN SITU -Tareas de mantenimiento realizadas por
el personal capacitado.
- Fabrica (mantenimiento,reparacion, y revision)-Tareas de mantenimiento
especializadas que requieren avanzadas capacidades de mantenimiento y
41
herramientas/equipamientos especiales no disponibles en la ubicación

operacional.
4.13.2.2 Sistemas habilitantes de mantenimiento
El proceso de mantenimiento incluye otros sistemas habilitantes que son diferentes de otros:
● Ambiente operacional-Las circunstancias del entorno y potenciales efectos en
algunas de las cosas que están operando.Ej equipamiento electrónico o mecánico
puede ser afectado por las altas temperaturas,vibraciones ,polvo,y otros parámetros
que constituyen al ambiente operativo.
● Soporte de suministro/PH&T- consistente de todas las acciones,necesarias para
determinar los requerimientos y para
adquirir,catalogar,recibir,almacenar,transferir,embalar,transportar,emitir,y disponer de
las partes,partes de reparación, y suministrar lo necesario para mantener el nivel de
operaciones requerido (Ej disponibilidad del sistema): La confiabilidad del sistema es
afectada cuando una acción de mantenimiento es retrasada por el sistema de
suministro.
● Sistema de formación - Proveer personal con los conocimientos y capacidades
requeridas para el mantenimiento apropiado del sistema.
● Dato técnico- Procedimiento, guias y listas de control necesarias para un apropiado
mantenimiento del sistema,incluyendo acciones preventivas (limpiar y ajustar), analizar
y diagnosticar, aislar fallas , localización de fallas,listas de partes,mantenimiento
correctivo (reemplazar y remover ),calibración, modificación y instrucciones de
actualización ,post-mantenimiento, validación ,etc.
● Facilidades e infraestructura- Facilidades (Ej,edificios,almacenes,hangares,caminos)
y la infraestructura(Ej. Servicios IT,combustible,agua,servicios eléctricos,tiendas de
maquinas,diques secos,ensayos de rangos) requeridas para el sistema de
mantenimiento.
● Herramienta y equipamiento de soporte- Herramientas comunes y de propósito
general (Ej herramientas de mano,medidores) y equipamiento de soporte (Ej. pruebas
de seteo,gruas) usados para soporte del sistema de mantenimiento.
● Diseño de interfaz/ingeniería sustentable - Intentos de interfaz de diseño para
“Diseño en” características compatibles con el sistema.Las consideraciones de
compatibilidad minimizan la marca logistica,maximizan la confiabilidad,aseguran el
mantenimiento efectivo,y direcciona a largo plazo los problemas relacionados a la
gestión de la obsolescencia ,refresco tecnológico, modificaciones y actualizaciones en
general usado bajo todas las condiciones de operaciones.La ingenieria de
sustentabilidad asegura la operacion continua y el mantenimiento del sistema con el
manejo de riesgos.
● Planificacion y gestion de mantenimiento - El foco del proceso de planificación de
mantenimiento define la accesibilidad,diagnostico,reparacion, y requerimientos
económicos,identificar factores que afectan a las tasas de utilización del diseño del
sistema.Identificar el diseño de compatibilidad del ciclo de vida,instalación,
mantenimiento ,y restricciones de operación; y proveer niveles de análisis de
reparacion (LORA)
4.13.2.3 Tecnicas de mantenimiento

● Condition -Based Maintenance (CBM) Es una estrategia para mejorar la
confiabilidad.
● Reliability -centered maintenance (RCM) Es una estrategia de mantenimiento para
efectivizar costos, para manejar las causas de fallas de los equipos [soportado para
modos de fallas,efectos,y análisis críticos(FMECA) y análisis de árbol de fallas(FTA)].
42
● Performance -based life cycle product support - Es una estrategia para economizar
el soporte del sistema.Más bien contratar mantenimiento necesario para sostener las
operaciones,el consumidor y el proveedor del servicio de acuerdo al performance de
resultados entregados.
4.14. Proceso de eliminación:
En este proceso de elimina los elementos o elementos de sistema de un uso previsto y

especificado, este proceso se realiza de acuerdo con la orientación, política y regulaciones
previstas.
La eliminación es un soporte del ciclo de vida del proyecto. Considera las restricciones que
deben ser equilibradas con las partes interesadas y las consideraciones de diseño. No olvidar
que existen preocupaciones ambientales. Como por ejemplo brindar un plan de reciclado de
materiales no reutilizables.
Actividades Salidas
Inputs
43
• Conceptos del ciclo de vida • Prepárese para la • Estrategia de eliminación

eliminación: Revise el • Sistema de eliminación de
• Sistema validado concepto de eliminación, eliminación de requisitos
seguir el plan de • Restricciones de
• Informe de operación eliminación, imponer eliminación
restricciones asociadas en el • Procedimiento de
• Reporte de mantenimiento sistema. Identificar elementos eliminación
que pueden ser reutilizados y • Sistema Dispuesto
no reutilizados. Establecer • Informe de eliminación
instalaciones de contención, • Registro de eliminación
ubicaciones de
almacenamiento; en el caso
de que se necesite
almacenar.
• Realice la eliminación:
Desmontar los elementos

para facilitar su manejo,
extraer todos los elementos y
materiales de desecho que
ya no son necesarios.
• Finalice la eliminación: -
Confirmar que no hay efectos
adversos de la eliminación
actividades y devolver el
medio ambiente a su
estado original.
- Mantener documentación de
todas las actividades de
eliminación y riesgos
residuales.
Tips y consideraciones en este proceso:
• La estrategia de eliminación y las consideraciones de diseño deberán ser actualizadas a lo

largo del ciclo de vida del sistema en respuesta a cambios en las leyes, regulaciones y política.
•• Considere donar un sistema obsoleto: muchos artículos, sistemas e información, de y el valor

histórico se han perdido para la posteridad.
44
CAPÍTULO 5: PROCESOS DE LA GESTIÓN TÉCNICA
5.1 INTRODUCCIÓN
Los ingenieros de sistemas tienen que interactuar continuamente con el gerente de proyectos.
Durante su ciclo de vida, el proyecto es visto de forma diferente por ambas partes. Gerente de
Proyectos (Project start-Project end), ingeniero de sistemas (Product idea-product disposal).
A lo largo de este capítulo se verán las distintas actividades que el SE debe realizar cómo
soporte a las actividades de Managment del proyecto.
5.1 PROCESO DE PLANIFICACIÓN DEL PROYECTO

El propósito del proceso de planificación del proyecto es para producir y coordinar planes
efectivos y viables.
La planificación del proyecto comienza con la identificación de un nuevo proyecto potencial y
continúa después de la autorización y activación del proyecto hasta su terminación. El proceso
de planificación del proyecto se realiza en el contexto de la organización. El modelo de ciclo de
vida del proceso de gestión establece e identifica políticas y procedimientos relevantes para la
administración y ejecutando un esfuerzo técnico; identificando el técnico tareas, sus
interdependencias, riesgos y oportunidades; y proporcionar estimaciones de los recursos y
presupuestos necesarios.
La planificación incluye la determinación de la necesidad de equipos especializados,
instalaciones y especialistas durante el proyecto para mejorar la eficiencia y la efectividad y
disminuir los excesos de costos.
5.2 EVALUACIÓN Y CONTROL DE LOS PROCESOS DEL PROYECTO
El propósito es evaluar si los planes están alineados y son factibles; determinar el estado del
proyecto, técnico y el rendimiento del proceso, y ejecución directa para asegurar que el
rendimiento es de acuerdo a los planes y horarios, dentro de los presupuestos proyectados,
para satisfacer los objetivos.
Las evaluaciones se programan periódicamente y para todos hitos y puertas de decisión. La
intención es mantener buenas comunicaciones dentro del equipo del proyecto y con las partes
interesadas, especialmente cuando son encontrados cambios.
El proceso usa estas evaluaciones para dirigir los esfuerzos del proyecto, incluida la redirección
del proyecto cuando el proyecto no refleja la madurez previa.
El proceso de evaluación y control del proyecto recopila datos para evaluar la adecuación de la
infraestructura del proyecto, la disponibilidad de recursos necesarios, y el cumplimiento de las
medidas de rendimiento del proyecto. Las evaluaciones también supervisan el progreso técnico
de la proyecto y puede identificar nuevos riesgos o áreas que requieren investigación adicional.
El rigor de la evaluación y control del proyecto depende directamente de la complejidad del
sistema de interés (SOI). El control del proyecto involucra acciones correctivas y preventivas
tomadas para asegurar que el proyecto está funcionando de acuerdo a los planes y horarios y
dentro de los presupuestos proyectados.
45
5.4 PROCESO DE GESTIÓN DE RIESGOS
El propósito del proceso de gestión de riesgos es identificar, analizar, tratar y monitorear los
riesgos continuamente.
Numerosas normas, directrices, y publicaciones informativas abordan los temas de gestión de
riesgo. A continuación hay varias definiciones consistentes con este concepto tradicional de
riesgo: El riesgo es la "combinación de la probabilidad de un evento y su consecuencia " con
las siguientes notas:
- El término riesgo generalmente se usa solo cuando hay al menos la posibilidad de
consecuencias negativas.
- En algunas situaciones, el riesgo surge de la posibilidad de la desviación del resultado
esperado o evento.
La gestión de riesgos es una enfoque disciplinado para hacer frente a la incertidumbre eso está
presente a lo largo de todo el ciclo de vida del sistema. Un objetivo principal de la gestión del
riesgo es identificar y administrar (tomar medidas proactivas) para manejar las incertidumbres
que amenazan o reducen el valor proporcionado por una empresa u organización.
5.5 PROCESO DE GESTIÓN DE CONFIGURACIÓN
El propósito de la Gestión de configuración es gestionar y controlar los elementos del sistema y

configuraciones a lo largo del ciclo de vida. CM (Configuration Manager) también maneja la
coherencia entre un producto y su definición de configuración asociada. Esto se logra
asegurando la eficacia en la gestión de la configuración durante la evolución del sistema, tanto
hardware como software, a lo largo de su ciclo de vida. Este objetivo se cumple estableciendo,
controlando, y mantenimiento las bases de datos de software y hardware. A medida que el
sistema madura y se mueve a través las etapas del ciclo de vida, la línea base del software o
hardware se mantiene bajo control de configuración.
La administración de configuración asegura que las funciones, rendimiento y características
físicas de un producto están debidamente identificados, documentados, validados y verificados,
y los cambios realizados sobre el mismo están identificados adecuadamente, revisados,
aprobados, documentados e implementados.
5.6 PROCESO DE GESTIÓN DE LA INFORMACIÓN
El propósito de la Gestión de la información es generar, obtener, confirmar, transformar,

retener, recuperar, diseminar y eliminar información, para las partes interesadas designadas.
Los impactos de las amenazas al acceso seguro, la confidencialidad, la integridad, la
disponibilidad de información puede paralizar la capacidad para hacer el trabajo.
La gestión de la información proporciona una base para la gestión y acceso a la información en
todo el ciclo de vida del sistema e incluso después de su final si es necesario. La información
designada puede ser de organización, proyecto, acuerdo, información técnica y de usuario.
5.7 PROCESO DE MEDICIÓN
El propósito del proceso de medición es recolectar, analizar e informar datos objetivos e

información para lograr una gestión efectiva y demostrar la calidad de los productos, servicios y
procesos.
El proceso de medición ayudará al SE a definir los tipos de información necesarios para apoyar
las decisiones de gestión del programa e implementar mejores prácticas para aumentar el
rendimiento. El objetivo de las métricas es observar el proceso y trabajar productos con
respecto al programa / proyecto y necesidades de la organización, incluida la puntualidad,
requisitos de rendimiento y atributos de calidad, conformidad con estándares, uso efectivo de
recursos, y mejora continua del proceso para reducir costos y tiempo de ciclo.
5.8 PROCESO DE ASEGURAMIENTO DE CALIDAD

El propósito del proceso de aseguramiento de la calidad es ayudar a asegurar la aplicación
efectiva de los procesos de gestión de calidad para el proyecto.
46
El aseguramiento de la calidad (QA) es ampliamente definido como el conjunto de actividades

a lo largo de todo el ciclo de vida del proyecto necesario para proporcionar la confianza
adecuada de que el producto o servicio cumple con los requisitos de las partes interesadas o
que un proceso se adhiere a la metodología establecida.
CAPÍTULO 6: PROCESOS DE ACUERDOS
6.1 INTRODUCCIÓN
El inicio de un proyecto comienza con la necesidad del usuario. Una vez que se percibe la
necesidad y los recursos se comprometen a establecer un proyecto, es posible definir los
parámetros de la relación de adquisición y suministro.
Los procesos de acuerdo definen las actividades necesarias para establecer un acuerdo entre
dos organizaciones. Un objetivo general de acuerdo procesos es identificar estas interfaces
externas y establecer los parámetros de estas relaciones, incluyendo e identificando las
entradas requeridas de las entidades externas y los resultados que se les proporcionarán. Esta
red de relaciones proporciona el contexto del entorno de los negocios de la organización y
acceso a futuras tendencias e investigaciones.
El ingeniero de sistemas por lo general tiene un papel de apoyo para el gerente de proyecto
durante las negociaciones y es responsable de las evaluaciones de impacto para cambios,
estudios de comercio sobre alternativas, evaluaciones de riesgo, y otros aportes técnicos
necesarios para las decisiones. Un elemento crítico para cada parte es la definición de criterios
de aceptación, tales como:
1. Cumplimiento porcentual de las SyRS
2. Requisitos de estabilidad y medidas de crecimiento, tales como la cantidad de requisitos
agregados, modificados o eliminado durante el intervalo de tiempo anterior (p. mes, trimestre,
etc.)
3. Porcentaje de cumplimiento de los requisitos de cada contrato documento: SOW, RFP, etc.
Estos criterios protegen ambos lados de la interacción de los negocios- el adquirente de ser
forzado a aceptar un producto con mala calidad y el proveedor de las acciones impredecibles
de un comprador voluble o indeciso.
6.1 PROCESO DE ADQUISICIÓN
El propósito del proceso de Adquisición es obtener un producto o servicio de acuerdo con los
requisitos del adquirente.
El proceso de adquisición se invoca para establecer un acuerdo entre dos organizaciones
según el cual una parte adquiere productos o servicios de la otra.
6.2 PROCESO DE SUMINISTRO
El proceso de suministro se invoca para establecer un acuerdo entre dos organizaciones en las
que una de las partes suministra productos o servicios a la otra.
El proceso de suministro es altamente dependiente de la gestión técnica, y procesos
organizativos de habilitación de proyectos.. Esto significa que el proceso de suministro es el
contexto más amplio en el que se aplican los otros procesos bajo el acuerdo. Esta sección está
escrita desde perspectiva de la organización proveedora.
47
CAPÍTULO 7: PROCESOS ORGANIZATIVOS DE

HABILITACIÓN DE PROYECTOS
Los procesos organizativos de habilitación de proyectos son competencia de la
organización (también conocida como empresa) y son usados para dirigir, habilitar,
controlar y apoyar el ciclo vida del sistema.
Este capítulo se centra en las capacidades de una organización relevantes para la realización
de un sistema; como se indicó anteriormente, ellos no están destinados a abordar la gestión
comercial general de objetivos, aunque a veces los dos se superponen. Las unidades
organizativas cooperan para desarrollar, producir, implementar, utilizar, apoyar, y retirar
(incluso el disposal) del sistema de interés (SOI). Los sistemas de habilitación también pueden
necesitar ser modificados para satisfacer las necesidades de los nuevos sistemas,
desarrollado, o adquiridolos si no existen.
7.1 PROCESO DE GESTIÓN DEL MODELO DE CICLO DE VIDA
El propósito del proceso de gestión del modelo de ciclo de vida es definir, mantener
y asegurar la disponibilidad de políticas, procesos del ciclo de vida, modelos de
ciclo de vida y procedimientos para el uso de la organización con respecto del
alcance de [ISO / IEC / IEEE 15288]
Las proposiciones de valor que se lograrán establecer en los procesos de toda la organización
por el uso de proyectos son los siguientes:
● Proporcionar rendimiento repetible / predecible en los proyectos en la organización
(esto ayuda al organización en la planificación y estimación de proyectos y en la
demostración de fiabilidad para los clientes)
● Prácticas de apalancamiento que han demostrado tener éxito para ciertos proyectos e
inculcarlos en otros proyectos a través de la organización (cuando corresponda)
● Permitir la mejora de procesos en toda la organización
● Mejorar la capacidad de transferir eficientemente al personal a través de proyectos
mientras los roles se definen y realizan de manera coherente.
● Habilita el aprovechamiento de lecciones que se de aprenden de un proyecto para
proyectos futuros para mejorar el rendimiento y evitar problemas
● Mejorar el inicio de nuevos proyectos (menor reinvención de la rueda)
Además, la estandarización en todos los proyectos puede permitir ahorro de costos mediante
economías de escala para actividades de apoyo (soporte de herramientas, documentación de
procesos, etc.).
Este proceso establece y mantiene un conjunto de políticas y procedimientos a nivel de
organización que apoyan la capacidad de adquirir y suministrar productos y servicios y
proporciona modelos de ciclo de vida integrado del sistema necesario para cumplir con los
planes estratégicos de la organización, políticas, metas y objetivos para todos los proyectos y
todas las etapas del ciclo de vida del sistema. Los procesos están definidos, adaptados y
mantenidos para apoyar los requisitos de la organización, unidades organizativas SE,
proyectos individuales y personal. La gestión de los procesos del modelo de ciclo de vida se
complementan con los métodos y herramientas recomendados.
48
7.2 PROCESO DE GESTIÓN DE INFRAESTRUCTURAS
El propósito del proceso de gestión de la infraestructura es proporcionar la

infraestructura y los servicios para apoyar la organización y los objetivos del proyecto a
lo largo de su ciclo de vida.
El trabajo de la organización es logrado a través de proyectos, que se llevan a cabo dentro del
contexto del entorno de la infraestructura. Esta infraestructura necesita ser definida y
comprendida dentro de la organización y el proyecto para asegurar la alineación de las
unidades de trabajo y el logro de los objetivos estratégicos generales de la organización. Este
proceso existe para establecer, comunicarse y mejorar continuamente entorno del proceso del
ciclo de vida del sistema. La Figura 7.3 es el diagrama de IPO para el proceso de gestión de la
infraestructura.
49
7.3 PROCESO DE GESTIÓN DE PORTAFOLIOS
El propósito del proceso de la Gestión del Portafolio es iniciar y mantener todos los
proyectos necesarios, suficientes y adecuados para cumplir los objetivos estratégicos
de la organización.
La administración del portafolio también proporciona una muestra del conjunto de proyectos,
sistemas e inversiones de la organización a partes externas interesadas como organizaciones
asociadas, inversores / fuentes de financiación, y organismos del gobierno.
Los proyectos crean los productos o servicios que generan ingresos para una organización. Por
lo tanto, la realización de proyectos exitosos requiere una asignación adecuada de fondos y
recursos y la autoridad para implementarlos cumpliendo los objetivos del proyecto. La mayoría
de las entidades comerciales administran sus recursos financieros utilizando procesos
monitoreo bien definidos y exhaustivos.
El proceso de gestión del portafolio también realiza la evaluación continua de los proyectos y
sistemas en su portafolio. Basándose en evaluaciones periódicas, los proyectos seguirán
recibiendo inversiones si tienen las siguientes características:
- Contribuir a la estrategia de la organización.

- Progreso hacia el logro de los objetivos establecidos.
- Cumplir con las directivas de la organización del proyecto.
- Se llevan a cabo de acuerdo a un plan aprobado.
- Proporcionan un servicio o producto que aún se necesite con beneficios aceptables.
De lo contrario, los proyectos pueden ser redirigidos o, en instancias extremas,
cancelados.
50
7.4 PROCESO DE GESTIÓN DE RECURSOS HUMANOS
El propósito del proceso de gestión de recursos humanos es proporcionar a la

organización con los recursos humanos necesarios y mantener sus competencias,
consistentes con las necesidades del negocio.
Todos los proyectos necesitan recursos para cumplir sus objetivos .Este proceso se ocupa de
los recursos humanos. Recursos no humanos, incluidas herramientas, bases de datos,
sistemas de comunicación, sistemas financieros y tecnología de la información, se abordan
utilizando el proceso de gestión de la infraestructura (Sección 7.2).
Los planificadores de proyectos determinan los recursos necesarios al anticipar las

necesidades actuales y futuras. El proceso de gestión de recursos humanos proporciona
mecanismos por los cuales la administración de la organización es consciente de las
necesidades del proyecto y el personal está programado para estar en su lugar cuando sea
solicitado. Si bien esto puede ser simplemente dicho, es difícil ejecutarlo. Los conflictos deben
ser resueltos, el personal debe ser entrenado, y los empleados tienen derecho a vacaciones y
tiempo fuera del trabajo.
La organización de gestión de recursos humanos recolecta las necesidades, negocia para

eliminar conflictos, y es responsable de proporcionar el personal. Ya que el personal calificado
no es gratuito, sus costos también se tienen en cuenta en las decisiones de inversión. La figura
7.5 es el diagrama IPO para el proceso de gestión de recursos humanos.
51
7.5 PROCESO DE GESTIÓN DE CALIDAD
El propósito del proceso de gestión de calidad es asegurar que los productos, servicios
e implementaciones del proceso reuna los objetivos organizativos y de calidad del
proyecto y logre la satisfacción del cliente.
El proceso de gestión de calidad hace visibles los objetivos de la organización hacia la

satisfacción del cliente. Como los controladores primarios en cualquier proyecto son tiempo,
costo y calidad, la inclusión de un proceso de gestión de la calidad es esencial para toda
organización. Muchos de los procesos del ciclo de vida del sistema están relacionados con
problemas de calidad, y esto forma parte de la justificación para el tiempo, dinero y energía
invertidos para establecer estos procesos en la organización. La aplicación de este manual es
un enfoque hacia la inserción de una disciplina de calidad en una organización.
El proceso de gestión de calidad (QM) establece, implementa y mejora continuamente el

enfoque en la satisfacción del cliente, las metas y los objetivos de la organización. Hay un
costo para la gestión de la calidad, así como un beneficio. El esfuerzo y el tiempo requeridos
para gestionar la calidad no deben exceder el valor general obtenido del proceso. La Figura 7.6
es el diagrama de IPO para el proceso de gestión de calidad.
52
7.6 PROCESO DE GESTIÓN DEL CONOCIMIENTO
El propósito del proceso de Gestión del Conocimiento es crear la capacidad y los activos que
permiten a la organización aprovechar las oportunidades para volver a aplicar el conocimiento
existente.
KM (Knwoledge Managment) es un área amplia que trasciende los límites de SE y la gestión de

proyectos, y hay un número de sociedades profesionales que se centran en él. KM incluye la
identificación, captura, creación, representación, difusión e intercambio de conocimiento a
través de grupos específicos de partes interesadas. Se basa en las ideas y experiencias de
individuos y/o grupos de organizaciones. El conocimiento incluye tanto el conocimiento
explícito (realización consciente del conocimiento, a menudo documentado y fácil de
comunicar) y el conocimiento tácito (internalizado en un individuo sin realización consciente) y
puede provenir de cualquiera de las personas (a través de la experiencia) u organizaciones (a
través de procesos, prácticas y lecciones aprendidas) (Alavi y Leidner, 1999; Roedler, 2010).
Dentro de una organización, el conocimiento explícito es usualmente capturado en su

entrenamiento, procesos, prácticas, métodos, políticas, y procedimientos. Por el contrario, el
conocimiento tácito es encarnado en los individuos de la organización y requiere técnicas
especializadas para identificar y capturar ese conocimiento, si debe transmitirse dentro de la
organización.
Los esfuerzos de KM generalmente se enfocan en objetivos organizacionales como un mejor

rendimiento, ventaja competitiva, innovación, intercambio de lecciones aprendidas, integración
y mejora continua de la organización (Gupta y Sharma, 2004). Por lo tanto, generalmente es
ventajoso para una organización adoptar un enfoque KM que incluye construir el marco, los
activos y la infraestructura para apoyar el KM.
La motivación para poner KM en su lugar incluye:
● Intercambio de información en toda la organización.

● Reducir el trabajo redundante debido a no tener la información necesaria en el
momento adecuado.
● Evitar "reinventar la rueda".
● Facilitar la capacitación, centrándose en las mejores prácticas.
● Capturar conocimiento que "saldría por la puerta" con jubilaciones y desgaste.
El último elemento de esta lista es una gran preocupación ya que vemos una pendiente
negativa en el suministro de ingenieros de sistemas. Como el porcentaje de ingenieros de
sistemas experimentados que se jubilan está aumentando, se vuelve aún más importante
capturar el conocimiento tácito que de otro modo se podría perder y luego poner ese
conocimiento a disposición de los ingenieros de sistemas en desarrollo.
En este manual, KM se ve desde una perspectiva de habilitación del proyecto de

la organización, es decir, cómo la organización admite el entorno del programa o proyecto con
los recursos en su sistema de KM. El apoyo brindado al proyecto puede venir de varias
maneras, que incluyen:
● Conocimiento capturado de expertos técnicos.

● Lecciones aprendidas capturadas de anteriores proyectos similares.
● Dominio de información de ingeniería que es reutilizable en el proyecto, como parte de
una línea de producto o familia de sistemas.
● Arquitectura o patrones de diseño que comúnmente son encontrados.
● Otros activos reutilizables que pueden ser aplicables al SOI.
La Figura 7.7 es el diagrama de IPO para el proceso de gestión del conocimiento
53
54
CAPÍTULO 8: PROCESO DE ADAPTACIÓN Y

APLICACIÓN DE INGENIERÍA DE SISTEMAS
Los estándares y los manuales abordan los modelos del ciclo de vida y procesos de ingeniería
de sistemas (SE) los cuales pueden o no aplicarse completamente a una organización y / o
proyecto determinado. Por ello normalmente van acompañados de una recomendación para
adaptarlos a una determinada situación.
El principio detrás de la adaptación es garantizar que el proceso cumple con las necesidades
del proyecto mientras se escala al nivel de rigor que permite que las actividades del ciclo de
vida del sistema se realicen con un nivel aceptable de riesgo. El modelo de ciclo de vida se
puede adaptar tal como se describe en el Capítulo 3. Los procesos pueden ser adaptados
como se describe en esta sección. Todos los procesos aplican a todas las etapas, la
adaptación determina el nivel del proceso que se aplica en cada etapa, pero ese nivel nunca es
cero. Siempre hay algo de actividad de cada proceso en cada etapa.
La figura 8.1 es un gráfico teórico para el balanceo entre llevar a cabo un proceso formal contra
el riesgo de excesos de costos y tiempo (Salter, 2003). Insuficiente esfuerzo en SE
generalmente es acompañado por un alto riesgo, sin embargo, como se ilustra en la Figura
8.1, un proceso demasiado formal también introduce un alto riesgo. Del mismo modo, mucho
rigor o actividades innecesarias para el proceso, aumentarán el costo y los impactos del
cronograma a cambio de muy poco o ningún valor agregado. La sastrería ocurre
dinámicamente a lo largo del ciclo de vida del sistema dependiendo del riesgo y el entorno
situacional, y debe ser continuamente monitoreado y ajustado según sea necesario.
Para ISO / IEC / IEEE 15288, la sastrería de procesos es el eliminando o adaptando de los
procesos para satisfacer las circunstancias particulares de una organización. Si bien la
adaptación ISO / IEC / IEEE 15288 se centra en la eliminación de elementos de los
procesos innecesarios o injustificados, permite adiciones y modificaciones también.
Este capítulo describe el proceso de adaptación de los modelos del ciclo de vida y procesos
de SE para cumplir con la organización y necesidades del proyecto. Este capítulo también
describe la aplicación de los procesos SE en varios sectores de productos y dominios, para
líneas de productos, para servicios, para empresas, y en micro y pequeñas empresas (VSMEs).
55
8.1 PROCESO DE ADAPTACIÓN
El propósito del proceso de Adaptación es adaptar los procesos de [ISO / IEC / IEEE
15288] para satisfacer circunstancias o factores particulares.
A nivel de organización, el proceso de adaptación acomoda estándares externos en el contexto

de los procesos organizacionales para satisfacer las necesidades de la organización. A nivel de
proyecto, el proceso de sastrería adapta los procesos organizacionales para las necesidades
del proyecto. La Figura 8.2 es el diagrama de IPO para el proceso de adaptación.
56
8.2 ADAPTACIÓN A UN PRODUCTO O ÁREA DE APLICACIÓN ESPECÍFICO
La disciplina de SE se puede aplicar en sistemas de cualquier tipo y tamaño. Sin embargo, eso
no significa que deba ser aplicado ciegamente de la misma manera en todos los sistemas.
Mientras los fundamentos de SE son los mismos, diferentes áreas requieren diferentes énfasis
para tener éxito.
Esta sección proporciona un punto de partida para las personas que buscan aplicar SE en
diferentes rubros. Si bien el libro aborda varios mercados, nos enfocaremos en el espacial que
es el de nuestro interés.
8.2.5 Sistemas espaciales

Los sistemas espaciales son aquellos sistemas que salen de la atmosfera terrestre o están
estrechamente asociados con su soporte y despliegue. Debido a los costos extremadamente
altos y al esfuerzo de desplegar activos en la órbita de la Tierra o más allá, los sistemas
espaciales típicamente requieren una alta confiabilidad sin más mantenimiento que los cambios
de software. Esto hace necesario que todos los elementos del sistema funcionen sin fallas o
ser compensados por complejas soluciones.
SE se desarrolló en gran parte debido a las demandas de la carrera espacial y las tecnologías
de defensa asociadas, como misiles balísticos. La disciplina es muy madura en este dominio y
no requiere adaptación.
Los énfasis clave de SE en el dominio del espacio son la validación y la verificación, prueba e
integración de sistemas altamente confiables y bien caracterizados. La Gestión de Riesgos
también es clave para determinar cuándo incorporar nuevas tecnologías y cómo reaccionar a
los requisitos cambiantes a través de desarrollos de varios años y de desafíos programáticos.
El enfoque tradicional V de SE tiene sus inicios en los sistemas espaciales, ya que suelen
concebir nuevos diseños, construidos e implementados por agencias o contratistas.
Se usa una gran cantidad de estándares en el rubro espacial. Las telecomunicaciones son una
fuente importante de los mismos, ya que los espectros deben negociarse globalmente.
Estándares eléctricos y de datos también se usan en muchas partes del los segmentes
terrenos y de vuelo. Las agencias espaciales nacionales y los ejércitos a menudo establecen
estándares (por ejemplo, la Cooperación Europea para Estandarización del espacio,
Estándares "MIL" de los Estados Unidos). Un excelente ejemplo de un manual de SE basado
en el espacio es el de la NASA (2007b). Como los sistemas espaciales son desplegados por
más países, la estandarización a través de ISO y IEEE se está volviendo más común para un
conjunto creciente de problemas de interoperabilidad.
57
8.3 APLICACIÓN DE LA INGENIERÍA EN SISTEMAS EN EL MANEJO DE LINEAS DE PRODUCTOS
La gestión de líneas de productos (PLM) es una combinación de producto, proceso,

administración y organización para migrar de la ingeniería de un solo sistema a un enfoque de
línea de producto. PLM puede apoyar el objetivo de mejorar la competitividad organizacional,
ya que disminuye el costo de desarrollo, aumenta la calidad y amplía el catálogo de productos.
Para el cliente, un enfoque de línea de producto permite ofrecer una familia de productos que
se adaptan a sus necesidades. Esto puede conducir a la optimización del producto o servicio,
el costo y el tiempo de adquisición, la calidad del sistema y el costo de propiedad.
Para la organización, PLM conduce a la optimización de su posición comercial y sus cargas

industriales, por lo general destacando la funcionalidad idéntica que conduce a la
estandarización.
Estas relaciones se muestran en la Figura 8.3.
Al implementar PLM, tanto el área de aplicación como los procesos de SE deben cambiar como
se muestra en Figura 8.4. Los productos de dominio (o productos genéricos) abordan los
requisitos de la línea de productos y son los resultados del trabajo de SE.
58
8.4 APLICACIÓN DE LA INGENIERÍA EN SISTEMAS PARA SERVICIOS
Esta sección presenta el concepto de SE para servicios, donde las metodologías SE están
adaptadas para incluir una disciplina, enfoque sistémico y orientación al servicio, centrado en el
cliente entre los diferentes interesados y recursos para nearreal- coreación del valor del tiempo
y entrega del servicio.
Varios investigadores y empresas son utilizados para analizar con una perspectiva
socioeconómica y tecnológica las interacciones del usuario final (cliente) con empresas
mediante el desarrollo de metodologías formales para favorecer la cocreación y la
productividad.
Los sistemas de servicio se pueden ver como SoS, donde sistemas individuales, heterogéneos
y funcionales están vinculados juntos para conseguir nuevas características/funcionalidades de
un metasistema y para mejorar la robustez, menor costo y aumentar la fiabilidad. Para sistemas
de servicio, la comprensión de las necesidades de integración entre sistemas débilmente
acoplados y entidades del sistema junto con los flujos de información requeridos tanto para las
operaciones, administración, mantenimiento y aprovisionamiento (OAM & P) del servicio
presenta grandes desafíos en la definición, diseño e implementación de servicios (Domingue et
al., 2009; Maier, 1998).
El típico ejemplo de industria dado de esta progresión hacia los servicios es el negocio
internacional Machines (IBM), que aún produce hardware pero ve su negocio como
abrumadoramente orientado al servicio en donde el hardware solo juega un papel secundario
en sus servicios de soluciones comerciales.
A medida que el mundo se vuelve más interconectado y las personas se vuelven más
educadas, las redes de servicios (creado por la interacción de las entidades del sistema) será
accesible desde cualquier lugar, en cualquier momento, por cualquier persona con los
derechos de acceso adecuados.
8.4.4 Valor de la SE en servicios

La SE aplicada a servicios trae un enfoque hacia el cliente para promover un servicio de
excelencia y facilitar su innovación a través del uso de tecnologías emergentes para proponer
la creación de nuevos sistemas de servicios. Los ingenieros de sistemas de servicios deben
jugar el papel de integradores teniendo en cuenta los requisitos de interfaz para la
interoperabilidad de las entidades del sistema, no solo para la integración, sino también para
los procesos y la organización requeridos para la experiencia óptima del cliente durante el uso
del servicio. El proceso de definición del diseño del servicio incluye la definición de métodos,
procesos y procedimientos necesarios para monitorear y rastrear los requisitos asociados al
mismo. Estos procedimientos aseguran que las fallas de cualquier entidad se detecten y no se
propaguen y perturben las operaciones del servicio (Luzeaux y Ruault, 2010).
Las economías del mundo continúan avanzando hacia la creación y entrega de servicios más
innovadores. Para preparar a los líderes del mañana, se necesitan nuevas disciplinas que
incluyen e integran diferentes habilidades y crean el conocimiento para apoyar tales servicios
globales.
59
8.5 APLICACIÓN DE LA INGENIERÍA EN SISTEMAS PARA EMPRESAS
Esta sección ilustra las aplicaciones de los principios de SE para la planificación, diseño,
mejora y operación de una empresa para transformarla y mejorarla continuamente
permitiéndole sobrevivir en una entorno globalmente competitivo. La SE aplicada a empresas
es la aplicación de principios, conceptos y métodos de SE a la planificación, diseño, mejora y
operación de un empresa. Además, la SE en empresas aborda más que simplemente la
resolución de problemas; también trata con la explotación de oportunidades para lograr de la
mejor manera los objetivos de la empresa.
8.6 APLICACIÓN DE LA INGENIERÍA EN SISTEMAS PARA PYMES
Las PyMEs se definen como organizaciones que tienen un pequeño número de empleados,
muchas veces menos de 50. Las contribuciones de las PyMEs al mundo de la economía está
bien documentado. Según algunas estimaciones, más del 98% del valor económico es
generado globalmente por las empresas con menos de 25 personas. Además, las PyMEs
contribuyen a los grandes sistemas empresariales y SoS, y son importantes y esenciales para
el éxito del sistema. La orientación de las PyMEs es genérica y aplicable a las funciones de SE
en cualquier rubro. Por supuesto, como con cualquier proyecto, debe aplicarse la adaptación
de las prácticas de SE teniendo en cuenta el riesgo asociado.
Debido a su pequeño tamaño, a las PyMEs a menudo les resulta difícil aplicar estándares
internacionales a sus necesidades comerciales. Las PyMEs típicas no tienen una
infraestructura integral, y el poco personal usualmente está desempeñando múltiples roles.
Una colección de cuatro perfiles (inicial, básico, intermedio, y avanzado) proporciona un

enfoque progresivo para poder aplicar los estándares a la mayoría de las PyMEs.
El perfil inicial se centra en las PyMEs nuevas y aquellas que trabajan en pequeños proyectos.
El perfil básico describe las prácticas de desarrollo del sistema de una sola aplicación por un
solo equipo y sin factores de riesgo especiales o situacionales. El perfil intermedio está dirigido
a las PyMEs que desarrollan proyectos múltiples, mientras que el perfil avanzado se aplica a
las que desean crecer como empresas independientes.
60
CAPÍTULO 9: CROSS-CUTTING SYSTEM ENGINEERING

METHODS
9.1 MODELOS Y SIMULACIONES
El beneficio de utilizar modelos y simulaciones radica en:
I. Confirman las necesidades de un sistema y sus comportamientos anticipados antes de

proceder con el desarrollo del sistema real.
II. Presentan un diseño claro y coherente a quienes llevarán a cabo el desarrollo, prueba,
despliegue y evolución del sistema, maximizando la productividad y minimizando el
error.
9.1.1 Modelos versus Simulaciones

No deben confundirse ambos conceptos.
Modelo: Es una abstracción o representación de un sistema, entidad, fenómeno o proceso de

interés. Otra definición puede ser una representación de alguna de alguna entidad en el mundo
físico. En el campo de la SE, un modelo que representa un sistema y su ambiente es de
particular importancia, para lo cual distintos tipos de modelos son usados para representar
distintos tipos de modelos.
Simulación: Es la implementación de un modelo/s en un ambiente específico que permite la

ejecución o use durante algún tiempo. Generalmente, las simulaciones proveen un medio para
analizar comportamientos dinámicos complejos de sistemas, software, hardware, personas y
fenómenos físicos. Una simulación computacional incluye el modelo analítico que se
representa en código ejecutable, las condiciones iniciales y otros datos de entrada, y la
infraestructura computacional. Una simulación, además de representar el sistema y su entorno,
debe proveer de métodos computacionales eficientes para resolver las ecuaciones.
9.1.2 Propósitos del Modelo

Una de las características principales del modelado es de definir claramente el propósito u
objetivo del modelo. Alguno de los propósitos para los cuales los modelos pueden servir
durante el ciclo de vida de un sistema incluyen:
● Caracterizar un sistema existente

● Formular y evaluar conceptos de misión y sistemas
● Diseñar la arquitectura del sistema y desglosar los requerimientos
● Soporte para la integración del sistema y la verificación
● Soporte para entrenamiento
● Dejar asentado el conocimiento y la evolución del diseño del sistema
9.1.3 Alcance del Modelo

El modelo debe tener un alcance acorde a su propósito. Por ejemplo, supongamos que vamos
a construir modelos para dar soporte al desarrollo de un avión. Un modelo de la arquitectura
del sistema podría describir la interconección a través de las distintas partes del avión, un
modelo de análisis de la trayectoria podría analizar su trayectoria y un modelo de análisis de
árbol de fallas podría evaluar las causas potenciales de una falla en la aeronave. Para cada
tipo de modelo, la amplitud, profundidad y fidelidad debe ser determinada para cumplir con
los propósitos del modelo.
La amplitud del modelo se refiere a la cobertura de los requerimientos de sistemas en

términos del grado al cual el modelo debe especificar los requerimientos funcionales,
interfases, performance y físicos, así como también otros requerimientos no funcionales.
61
La profundidad del modelo indica el grado de descomposición del modelo desde el contexto
del sistema hacia los elementos del mismo.
La fidelidad del modelo indica el nivel de detalle que el modelo debe representar para
cualquier parte del mismo. La fidelidad puede también referirse a la precisión de un modelo
computacional, como el tiempo del paso de tiempo requerido para la simulación.
9.1.4 Tipos de Modelos y Simulaciones

9.1.4.1 Tipos de Modelos
Existen distintos tipos de modelos que se concentran en distintos aspectos de acuerdo a lo que
uno quiera mostrar, tales como los modelos funcionales, de performance, de confiabilidad, de
supervivencia, disponibilidad operacional y costo.
Un modelo Taxonómico como el que se muestra abajo es útil para mostrar una ilustración del
modelo pero no necesariamente provee una visión exhaustiva del mismo. Otras clases pueden
ser:
● Modelos Físicos: Representan un sistema real, como un modelo de un avión o un

modelo de túnel de viento, o una representación as abstracta coo un modelo usando la
computadora.
● Modelos abstractos: Pueden tener distintas formas para representar un sistema,
entidad, fenómeno o proceso, los cuales varían en el grado de formalismo.
● Modelos Informales: Se modela el sistema con una simple herramienta de dibujo o
con palabras. Sin embargo, esta forma de modelar carece de presición y posibilita
ambigüedades en la representación. Para que un modelo de este tipo sea considerado
por la SE debe cumplir con ciertos criterios.
● Modelos Formales: Se pueden clasificar como modelos geométricos, cuantitativos
(matemáticos) y/o modelos lógicos (o modelos conceptuales). Estos últimos suelen
representarse por medio de gráficos o tablas.
Algu
nos
eje
mpl
os
de
mod
elos
de
sist
ema
s
pue
den
incl
uir (ISO/IEC/IEEE 15288):
● Modelo Funcional: captura la funcionalidad del sistema y de sus interfaces

● Modelo de Comportamiento: Captura el comportamiento global de las funcionalidades
del sistema
● Modelo Temporal: captura aspectos relativos al tiempo de la arquitectura
● Modelo Estructural: Captura los elementos del sistema y sus interfaces físicas
● Modelo Másico: Capturan aspectos relacionados a la masa del sistema
● Modelo de Capas: Captura las ubicaciones absolutas y relativas de los elementos del
sistema
62
● Modelo de Redes: Captura el flujo de recursos a travez de las funciones de sistema o

elementos.
9.1.4.2 Tipos de Simulaciones

Existen varios tipos.
● Simulaciones Físicas: Se utilizan modelos físicos y permiten replicar una cantidad

relativamente pequeña de atributos de un sistema con un alto grado de exactitud
(fidelidad). Generalmente son costosos y se usan cuando no es posible realizar
simulaciones basadas en computadoras. Un ejemplo puede ser ensayos en un túnel de
viento.
● Simulaciones basadas en la computadora: Pueden dividirse en subtipos de acuerdo
al grado de computo requerido, por ejemplo, de eventos discretos, de tiempo continuo
o de elementos finitos. En procesos estocásticos suelen utilizarse simulaciones de
Monte Carlo. La tendencia actual es dividir la simulación computacional o módulos de
manera de poder reutilizar modelos computacionales.
● Simulaciones de hardware y/o reales: Son simulaciones qe se ejecutan en tiempo
real. Tienen un alto grado de fiabilidad pero pueden ser costosas, especialmente si se
requieren simulaciones físicas como por ejemplo generación de escenas de
movimiento o visuales.
9.1.5 Desarrollando Modelos y Simulaciones

Los modelos y simulaciones deben ser planeados y tener un seguimiento como cualquier otro
proceso dentro de la SE, es decir, deben verificarse, validarse y acreditarse para poder ser
utilizados para un dado propósito.
9.1.6 Integración del Modelo y la Simulación

Distintos tipos de modelos y simulaciones puede que sean utilizados como parte de una
aproximación basad en modelos. Por lo cual, la clave está en facilitar la integración de los
modelos y simulaciones a través de las múltiples dominios y disciplinas (eléctrica, mecánica,
ELECTRÓNICA = GROSOS, y de software). Para ello los modelos y simulaciones deben
mantener una coherencia semántica (las variables deben llamarse con el mismo nombre y
tener el mismo significado en los distintos modelos). Para lograr esta interoperabilidad, suelen
utilizarse transformaciones de modelos.
9.1.7 Gestión del Modelo

La gestión de los modelos y simulaciones a lo largo del ciclo de vida del sistema incluye la
gestión de la configuración relativo a las versiones y control de cambios. Otro punto importante
es el tema de la validación continua, es decir, a medida que se van introduciendo cambios,
estos deben garantizar que se mantenga el mismo grado de representación del sistema.
9.1.8 Modelos Estandars

Utilizar modelos estándar permite disminuir la brecha entre disciplinas, proyectos y
comunicaciones entre organizaciones, lo cual puede reducir el tiempo de entrenamiento de los
usuarios al pasar de un proyecto a otro y además, reusar modelos. Los modelos estándar
incluyen el lenguaje, intercambio de datos entre modelos y la transformación de un modelo a
otro para lograr una interoperabilidad semántica.
9.1.9 Lenguajes de Modelado

Pueden utilizar símbolos gráficos (por ejemplo, un modelo funcional de flujo) y/o enunciados
textuales (código en Fortran).
63
SysML ha surgido como un lenguaje de modelado de sistemas. Sus tipos de diagramas se
muestran en la siguiente figura:
● Diagrama de Paquetes (pkg): Se usa para organizar el modelo en paquetes que

contienen otros elementos del modelo. Facilita la visualización del modelo así como
también el acceso y control de cambios.
● Diagrama de Requerimientos (req): Explicita los requerimientos de manera textual lo
cual facilita la trazabilidad entre requerimientos y el diseño, análisis y verificación del
modelo.
● Diagrama de Estructuras:
o Diagrama de Definición de Bloques (bdd): Describe la jerarquía del sistema y la
clasificación de los elementos del mismo.
o Diagrama de Bloques Internos (ibd): Representa la estructura interna de un
sistema en términos de cómo sus partes están interconectadas a través de
puertos y conectores.
● Diagramas de Comportamiento:
o Diagrama de Casos de Uso (cu): Provee una descripción de alto nivel de las
funcionalidades del sistema en término de cómo los usuarios y el entorno
utilizan el sistema para lograr sus objetivos.
o Diagramas de Actividad (act): Representa la transformación de las entradas en
las salidas a través de una secuencia controlada de acciones.
o Diagramas de Secuencia (sd): Representa la interacción del intercambio de los
mensajes ordenados por tiempo entre partes que conforman el sistema.
o Diagrama de Máquina de Estado (stm): Describe el estado de un sistema o sus
partes, las transiciones entre estados, las acciones que ocurren dentro un
estado o sobre transiciones, entradas o salidas, y los eventos que disparan
transiciones.
● Diagrama Paramétrico (par): Representa restricciones en los valores de las
propiedades del sistema necesarias para dar soporte al análisis detallado de ingeniería.
Estas restricciones incluyen performance, confiabilidad y propiedades de mas entre
otras. SysML puede integrarse con otros modelos de análisis de ingeniería y
herramientas para ejecutar dicho análisis.
Un sistema particular puede que no requiera utilizar todos los diagramas antes mencionados,
sino un subconjunto de ellos.
64
9.1.10 Herramientas de Modelado y Simulación

Las herramientas de modelado son utilizadas para construir modelos utilizando un lenguaje de
modelado. Por ejemplo, la herramienta de modelado brinda una paleta de símbolos o bloques
para construir el modelo.
9.1.11 Indicadores de calidad del Modelo

No debe confundirse el concepto de calidad de un modelo con la calidad del diseño que el
modelo representa. Por ejemplo, uno puede tener una alta calidad de un modelo computacional
para diseñar una silla, sin embargo, si la silla falla al ser ensayada, la calidad del diseño es
mala.
La calidad de un modelo se mide en términos de reglas de guía o recomendaciones de

modelado como por ejemplo, para un modelo geométrico, definir primero el sistema
coordenado, las dimensiones y las tolerancias de acuerdo a las convenciones normalmente
utilizadas.
9.1.12 Modelo y Métricas basadas en Simulación

Distintos tipos de modelos y simulaciones proveen distintos tipos de información que permiten:
● Evaluar el progreso: En términos de cuantos requerimientos han sido satisfechos por el

diseño y a través de tests.
● Estimar esfuerzos y costos
● Evaluar la calidad técnica y el riesgo
● Evaluar la calidad del modelo
En muchos casos, el modelo también puede ser utilizado para estimar los costos relacionados
a la SE.
9.2 INGENIERÍA DE SISTEMAS BASADA EN MODELOS (MBSE)
El INCOSE define el MBSE como “la aplicación formal del modelado para dar soporte a los
requerimientos de sistemas, diseño, análisis, verificación y validación que comienzan en la fase
de diseño conceptual y continúan a lo largo del desarrollo y en fases posteriores del ciclo de
vida de un proyecto”.
● La MBSE tiene los siguientes beneficios:

● Mejora la Comunicación
● Aumenta la capacidad para gestionar la complejidad del sistema (múltiples
perspectivas)
● Mejora la calidad del producto (modelo preciso y no ambiguo)
● Mejora la captura del conocimiento (se confecciona la información de una manera mas
estandarizada lo que facilita a su vez el reuso de la misma. Esto se traduce en una
reducción del tiempo de desarrollo de un proyecto nuevo y los costos para modificar
uno existente)
● Mejora la habilidad para enseñar y aprender conceptos de SE (se utilizan conceptos
claros y no ambiguos)
En el enfoque tradicional de SE basada en documentos existe un volumen de información muy
grande ya que todo se documenta, lo cual dificulta su mantenimiento, sincronización y
evaluación en términos de la calidad (completitud, consistencia, etc.).
En el enfoque MBSE mucha de esta información se concentra en un modelo de sistema o en

un conjunto de modelos. El grado en el cual esta información se captura en modelos y se
mantiene a lo largo del ciclo de vida depende del alcance que se le dé a la MBSE.
65
9.3 MÉTODO DE INGENIERÍA DE SISTEMAS BASADA EN FUNCIONES (FBSE)
Este enfoque se concentra sobre la arquitectura funcional del sistema. Una función es una
tarea específica, una acción o una actividad que debe ser realizada para lograr un beneficio
deseado. Una función puede estar acompañada por una o más elementos del sistema que
comprenden le hardware, software, firmware, facilidades, personal y datos de procesamiento.
FBSE describe lo que el sistema podrá hacer, no como va a hacerlo. Idealmente, este proceso
comienza después de que todos los requerimientos de sistema han sido definidos
completamente, pero esto rara vez se logra por lo cual esta tarea deberá llevarse a cabo de
manera iterativa.
El proceso de FBSE es iterativo, incluso dentro de una única etapa durante el ciclo de vida del
sistema y comienza al nivel más alto como un conjunto de funciones que son definidas en el
documento de requerimientos aplicable o especificaciones. A continuación se muestra el
proceso típico de
cómo ir
desglosando la arquitectura funcional del sistema:
A continuación se muestra el proceso iterativo de cómo ir realizando las descomposiciones y

ubicaciones alternativas para luego definir las interfases:
Con cada iteración de FBSE, descomposiciones alternativas son evaluadas y todas las
interfaces son definidas.
Los productos de FBSE pueden tomar distintos formatos dependiendo de la etapa específica
del proyecto y de la técnica específica usada para desarrollar la arquitectura funcional. Los
siguientes son algunos de las salidas que se pueden generar con FBSE:
● Diagramas de entrada y salidas del proceso (IPO): Son diagramas de alto nivel que
muestran el flujo de datos. No muestran la descomposición del sistema.
● Diagramas de Comportamiento
66
● Diagramas de Control de Flujo: Dentro de ellos, puden ser: Diagramas de caja, de flujo
y de transición de estados
● Diagramas de Flujo de Datos (DFD)
● Diagramas de relación de Entidades (ER)
● Diagrama de Bloques de Flujos Funcionales (FFBD)
● Diagramas de Definición Integrada para el Modelado Funcional (IDEF)
● Diccionarios de Datos
● Modelos
● Resultados de Simulación
Las herramientas que pueden utilizarse para FBSE son:
● Herramientas de Análisis
● Herramientas de Modelado y Simulación
● Herramientas para realizar Prototipos
● Herramientas para hacer seguimientos de los Requerimientos
9.4 MÉTODO DE INGENIERÍA DE SISTEMAS ORIENTADO A OBJETOS (FBOO)
Este enfoque hace más flexible a la arquitectura y la extensibilidad del sistema para adaptarse
a nuevas tecnologías y cambios de requerimientos. También facilita la integración con
desarrollando softwares orientados a objetos, hardware y métodos de verificación y validación.
En la figura siguiente se muestran las técnicas y conceptos que constituyen OOSEM.
Los requerimientos de sistema y proceso de diseño se descomponen en las siguientes

actividades de alto nivel para un enfoque OOSEM, como se muestra en la figura siguiente:
67
● Analizar los Necesidades de los Usuarios

● Analizar los Requerimientos de Sistema
● Definir la Arquitectura Lógica
● Sintetizar las Arquitecturas Físicas Candidatas
● Optimizar y Evaluar las Alternativas
● Gestionar la Trazabilidad de los Requerimientos
● Validar y Verificar el Sistema
9.5 CREACIÓN DE PROTOTIPOS
La creación de prototipos es una técnica que puede mejorar significativamente la probabilidad

de proporcionar un sistema que satisfaga las necesidades del usuario. Además, un prototipo
puede facilitar tanto la comprensión como la dimensión de las necesidades del usuario y los
requerimientos de las partes interesadas. Dos tipos de prototipos son comúnmente utilizados:
Rápido y Tradicional.
Un prototipo rápido es un tipo particular de simulación rápidamente ensamblada desde un

menú de elementos físicos, gráficos o matemáticos existentes.
Un prototipo Tradicional es una herramienta que puede reducir el riesgo o la incertidumbre. Un

prototipo parcial es usado para verificar elementos críticos del sistema de interés. Un prototipo
completo representa el sistema en su totalidad.
9.6 GESTIÓN DE INTERFASES
La gestión de interfaces tiene un impacto directo en la reducción del costo de proyecto, la

programación y las performances técnicas. En general, las interfaces son identificadas dentro
del proceso de definición de la arquitectura, mientras los modelos de arquitectura son
desarrollados. Los requerimientos de interface se refinan durante el proceso de definición de
los requerimientos de sistema. Al igual que el proceso de definición del sistema, la definición de
interfaces se va ajustando iterativamente.
Muchos proyectos tienen la necesidad o el beneficio de utilizar interfaces estándar, como por
ejemplo protocolos estándar de internet o arquitecturas de sistemas modulares abiertas.
La comunicación es de vital importancia para asegurar una buena gestión de interfaces por lo
cual muchos sistemas incorporan el uso de un Grupo de Trabajo de Control de Interfaces
(ICWG).
68
La gestión de interfaces provee un método efectivo y simple para elaborar documentos

formales y tener un seguimiento del intercambio de información a medida que el ciclo de vida
del sistema avanza.
Existen distintos métodos para analizar interfaces, los cuales ayudan a identificar y entender
las interfaces en el contexto del sistema, los elementos del sistema y/o las interfaces del
sistema.
Los diagramas N² presentan un enfoque esquemático para analizar interfaces, lo cuales

pueden ser utilizados en etapas tardías del desarrollo del proceso para analizar y documentar
las interfaces físicas entre elementos del sistema. Es un matriz visual, la cual requiere para ser
elaborada de manera correcta que el SE defina todas las interfaces del sistema de manera
clara. En la figura siguiente se muestra un ejemplo de diagramas N²:
Las funciones de sistema o elementos físicos se muestran en la diagonal del diagrama. El resto
de los casilleros en la matriz NxN representa las interfaces de salida y de entrada.
Otros métodos de análisis útiles para definir interfaces son:
● Matriz Estructural de Diseño (DSM): Similar al diagrama N²

● Diagrama de Bloques Internos (ibd): Lo implementa el lenguaje SysML y se utiliza para
describir la estructura interna de un sistema en términos de sus partesm puertos y conectores.
9.7 DESARROLLO DE PRODUCTOS INTEGRADOS Y PROCESOS
El desarrollo de productos integrados (IPD) reconoce la necessidad de considerar todos los

elementos durante el ciclo de vida del producto, desde su concepción hasta su fin de vida. Esto
incluye la calidad, el costo, la programación, los requerimientos de usuario y su manufactura y
soporte.
El desarrollo de productos y procesos integrados (IPPD) además reconoce la importancia del

proceso, para lo cual las siguientes definiciones son aplicables:
● Equipo de Desarrollo de Productos Integrados (IPDT): Equipo multidisciplinario que

distribuye el producto o proceso ya definido.
● IPPD: Se lleva a cabo simultaneamente al desarrollo de un diseño de producto o
sistema, los métodos de manufactura de los mismos.
● Ingeniería Concurrente: Se dispone de un ambiente el el cual personas de distintas
disciplinas trabajan juntas y comparten datos a lo largo de todas las etapas del ciclo de
vida del producto.
69
9.8 LEAN SE
El Lean Thinking es un proceso dinámico, enfocado en el conocimiento y el cliente a través del

cual la gente en una determinada empresa elimina continuamente el desperdicio en vistas de
crear valor agregado a la empresa. El Lean SE es la aplicaión de los principios, prácticas y
herramientas a la SE para mejorar el valor del producto a entregar a los usuarios interesados.
Existen tres aspectos fundamentales para entender el Lean Thinking:
● Valor: En Lean SE, valor se define simplemente como Aseguramiento de Misión y

satisfacción de clientes y todos los usuarios interesados, lo que implica un mínimo
desperdicio, mínimo costo y una programación lo mas corta posible en tiempo.
● Desperdicio: Son los trabajos o procesos que no agregan valor al producto o servicio a
los ojos del cliente. Sólo agrega costo y tiempo. Algunos ejemplos para la SE son:
o Procesos sobre valuados
o Esperas relacionadas a información o materiales
o Movimientos innecesarios
o Sobre producción
o Transporte
o Inventario
o Defectos
o Desperdicio de potencia humano
● Proceso de crear valor sin desperdicio o Lean Principles: Womack y Jones (1996)
basaron el proceso de crear valor sin desperdicio en 6 principios, abreviados como
value, value stream, flow, pull, perfection y respect for people, los cuales se muestran
en la siguiente figura:
9.9 SE ÁGILES
La Agilidad es la capacidad que puede exhibir un sistema y proceso para mantenerse

operacionalmente efectivo bajo condiciones impredecibles, inciertas y ante cambios. Esto se
traduce en la SE Agíl en el proceso de Gestión de Riesgos. Si un sistema es muy rígido ante
cambios, la evolución de los requerimientos causa que se repitan trabajos realizados con
anterioridad y de esta manera se desperdicien recursos, lo cual conlleva a elevar los costos y
tiempos. Resumiendo, una arquitectura de sistema ágil se corresponde con una arquitectura
adecuada y un diseño modular lo cual reduce los riesgos asociados a que cambios en los
requerimientos (su evolución natural a lo largo de la visa útil del proyecto) no impacten
significativamente en las características técnicas, costos y programación del sistema.
70
Los principios para diseñar una arquitectura ágil se concentran en tres subgrupos: reusable,
reconfigurable y escalable, y se resumen a continuación:
● Reusable: Dentro de esta categoría tenemos:

o Módulos Encapsulados: Módulos independientes.
o Facilidades de las Interfaces: Interfaces estandar que faciliten su interoperatividad
con otros módulos y su remoción.
o Facilidades de Reuso
● Reconfigurable: Dentro de esta categoría tenemos:
o Interacciones Peer-Peer: comunicaciones entre módulos directamente con una
relación homóloga y en lo posible se relacionan paralelamente (se prefiere paralelo
antes que secuencial).
o Información y Control Distribuido: Los módulos se dirigen por objetivos mas que
por métodos, y las decisiones se hacen maximizando el conocimiento, y la
información es asociada localmente y accesible globalmente.
o Compromiso Diferido
o Auto Organización
● Escalable: Dentro de esta categoría tenemos:
o Estándares que evolucionan
o Redundancia y Diversidad
o Capacidad Elástica
71
CAPÍTULO 10: ACTIVIDADES ESPECIALES DE LA

INGENIERÍA
El objetivo del capítulo es dar suficiente información al ingeniero de sistemas para que entienda
la importancia de cada especialidad de las ingenierías.
Los sistemas son diseñados siempre teniendo en cuenta el concepto de asequibilidad.
Los [aspectos técnicos] generalmente se consideran primero, los [aspectos] económicos son
tenidos en cuenta más adelante.
10.1 ANÁLISIS DE ASEQUIBILIDAD, DE COSTO-EFECTIVIDAD Y COSTO DE CICLO DE VIDA
10.1.1 Análisis de Asequibilidad

Asequibilidad es el equilibrio entre el rendimiento del sistema, los costos y las limitaciones de
programación a lo largo de la vida del sistema, mientras que satisface las necesidades de la
misión junto con la inversión estratégica y las necesidades de la organización.
El diseño para la asequibilidad es la práctica de ingeniería de sistemas de equilibrar el

rendimiento y el riesgo del sistema con limitaciones de costos y cronogramas sobre la vida útil
del sistema, satisfaciendo las necesidades operativas del sistema junto con la inversión
estratégica y el valor de las partes interesadas en evolución.
Para definir la accesibilidad para un programa o sistema en particular (vea la Fig. 10.3 como un
ejemplo de un rango de asequibilidad), debemos definir los componentes seleccionados de
accesibilidad. Como tal, se podría especificar lo siguiente:
1. Capacidades requeridas:
a. Identifique las capacidades requeridas y la fase de tiempo para la inclusión de
las capacidades.
2. Rendimiento de las capacidades requeridas:
a. Identifique y especifique los ME necesarios para cada una de las capacidades.
b. Defina la fase de tiempo para lograr los MOEs.
3. Presupuesto:
a. Identifique los elementos del presupuesto para incluir en la evaluación de
asequibilidad.
b. Presupuesto por fases, ya sea
i. para cada uno de los elementos del presupuesto o
ii. como el presupuesto total.
72
Al menos uno de los elementos de asequibilidad debe designarse como el criterio de decisión
que se utilizará en un estudio de comercio o como la base para adjudicar un contrato. Los
elementos de asequibilidad que no están designados como los criterios de decisión se
convierten en restricciones, junto con las limitaciones que se especifican.
10.1.2 Análisis de Costo-Efectividad

El análisis de costo-efectividad (CEA) es una forma de análisis comercial que compara los
costos relativos y las características de rendimiento de dos o más cursos de acción. A nivel de
sistema, CEA ayuda a derivar el rendimiento crítico del sistema y los requisitos de diseño y
respalda la toma de decisiones basada en datos.
CEA comienza con objetivos claros y un conjunto de alternativas para alcanzar esos objetivos.
Las comparaciones solo deben hacerse para alternativas que tienen objetivos similares. Un
CEA directo no puede comparar opciones con diferentes metas y objetivos.
Lo que CEA agrega es la capacidad de considerar los resultados de diferentes alternativas en

relación con los costos de lograr esos resultados.
10.1.3 Análisis de Costo de Ciclo de Vida (LCC)

LCC se refiere al costo total incurrido por un sistema o producto a lo largo de su vida. Este
costo "total" varía según las circunstancias, los puntos de vista de las partes interesadas y el
producto.
El ingeniero de sistemas debe considerar los costos desde varios aspectos y ser consciente de
las perspectivas de las partes interesadas. En algunos estudios, el LCC se compara con el
costo total de propiedad (TCO), pero muchas veces estas medidas solo incluyen los costos una
vez que los sistemas se compran o adquieren.
El análisis LCC ayuda al equipo del proyecto a comprender el impacto total en el costo de una
decisión, comparar entre las alternativas del programa y respaldar los estudios comerciales
para las decisiones tomadas a lo largo del ciclo de vida del sistema. LCC normalmente incluye
los siguientes costos:
• Costos conceptuales: costos para los esfuerzos iniciales de desarrollo conceptual (mano de
obra promedio y los intervalos de programación, costos generales y administrativos).
• Costos de desarrollo: costos para los esfuerzos de desarrollo del sistema.
• Costos de producción: generalmente impulsados por herramientas y costos de materiales

para sistemas de gran volumen.
• Costos de utilización y soporte: normalmente se basan en suposiciones futuras para la

operación y el mantenimiento continuos del sistema.
• Costos de retiro: los costos por eliminar el sistema de la operación e incluye una estimación
de los costos de intercambio o rescate.
73
10.2 COMPATIBILIDAD ELECTROMAGNÉTICA
EMC es la disciplina de ingeniería relacionada con el comportamiento de un sistema en un

entorno electromagnético (EM). Se considera que un sistema es compatible
electromagnéticamente cuando puede funcionar en un entorno EM junto con otros sistemas o
elementos del sistema y no causa un mal funcionamiento a otros sistemas o elementos del
sistema.
Los requisitos de EMC son entradas para las etapas de concepto y desarrollo. Es importante
que los requisitos de EMC se fijen al comienzo del diseño físico, ya que el diseño de EMC
incluye implementaciones de hardware mecánico y eléctrico / electrónico que no forman parte
de los demás requisitos funcionales.
Un enfoque estructurado para el control de la interferencia durante la etapa de diseño de un

sistema es desarrollar un plan de control de EMI. El plan de control de EMI normalmente
incluye todos los requisitos de EMC, estrategia de zonificación, filtrado y blindaje, cableado y
detalle de diseño mecánico y eléctrico perteneciente a EMC.
10.3 INGENIERÍA AMBIENTAL Y ANÁLISIS DE IMPACTO
El enfoque del análisis de impacto ambiental se basa en los efectos nocivos potenciales del
desarrollo, la producción, la utilización, el apoyo y las etapas de jubilación de un sistema
propuesto.
La serie ISO 14000 de normas de gestión ambiental (ISO, 2004) es un excelente recurso para
organizaciones para analizar y evaluar sus operaciones y sus impactos en el medio ambiente.
Dos elementos clave del éxito de esta iniciativa fueron el monitoreo continuo del estado
ambiental y la integración de las preocupaciones ambientales en los requisitos del propietario.
10.4 ANÁLISIS DE INTEROPERABILIDAD
La interoperabilidad depende de la compatibilidad de los elementos de un sistema grande y

complejo (que puede ser un SoS o una familia de sistemas (FoS)) para funcionar como una
sola entidad. Esta característica es cada vez más importante a medida que el tamaño y la
complejidad de los sistemas continúan creciendo.
Los estándares también han crecido en número y complejidad a lo largo del tiempo, sin
embargo, el cumplimiento de las normas sigue siendo una de las claves de la interoperabilidad.
74
10.5 INGENIERÍA DE LOGÍSTICA
La ingeniería de logística, que también se conoce como ingeniería de soporte de productos, es

la disciplina de ingeniería relacionada con la identificación, adquisición, gestión y
aprovisionamiento de todos los recursos de soporte necesarios para mantener la operación y el
mantenimiento de un sistema. La logística debe abordarse desde la perspectiva del ciclo de
vida y debe considerarse en todas las etapas de un programa y, especialmente, como parte
inherente de la definición y desarrollo del concepto del sistema.
El alcance de la ingeniería logística es, por lo tanto:
1. Determinar los requisitos de soporte logístico,

2. Diseñar el sistema para soporte,
3. Adquirir o crear el soporte, y
4. Proporcionar soporte logístico rentable para un sistema durante las etapas de
utilización y soporte (es decir, operaciones y mantenimiento).
10.5.1 Análisis de Compatibilidad

El análisis de compatibilidad es un proceso analítico iterativo mediante el cual se identifican y
evalúan los requisitos de soporte logístico para un sistema. Entre ellos se encuentran:
● Análisis de falla funcional: se utiliza una estructura de desglose funcional como

referencia para realizar FMECA funcional y / o análisis de árbol de fallas (FTA) y
análisis de diagramas de bloques de fiabilidad (RBD).
● Definición física: durante el diseño del sistema, se debe desarrollar la estructura de
desglose físico de un sistema para ayudar a identificar la ubicación real de los
elementos en el sistema.
● Identificación y optimización de tareas: las tareas de mantenimiento correctivo se
identifican principalmente con FMECA, mientras que las tareas de mantenimiento
preventivo se identifican mediante RCM.
● Análisis detallado de la tarea
● Especificaciones del elemento de soporte
● Entregables de soporte
● Modelado y simulación de soporte
● Prueba y evaluación de soporte
● Grabación y acción correctiva
10.6 ANÁLISIS DE FABRICACIÓN Y PRODUCTIVIDAD
La capacidad de fabricar o producir un elemento del sistema es tan esencial como la capacidad
de definirlo y diseñarlo correctamente. Un producto diseñado que no se puede fabricar causa
una reprogramación del diseño y retrasos en los programas con sobrecostos asociados.
El análisis de la productividad es una tarea clave en el desarrollo de productos de bajo costo y

calidad. Los requisitos críticos de producibilidad son identificados durante el análisis y diseño
del sistema e incluido en el análisis de riesgo del programa, si es necesario. Del mismo modo,
se evalúan los elementos de larga duración, las limitaciones de material, los procesos
especiales y las limitaciones de fabricación. La simplificación del diseño también considera el
ensamblaje y el desmontaje listos para facilitar el mantenimiento y la preservación del material
para el reciclaje. La selección de métodos y procesos de fabricación se incluye en decisiones
tempranas.
Los análisis de fabricación se basan en el concepto de producción y el concepto de soporte.

Las consideraciones de la prueba de fabricación se comparten con el equipo de ingeniería y se
tienen en cuenta en los equipos de prueba y automatizados de prueba incorporados.
75
10.7 INGENIERÍA DE PROPIEDADES DE MASA
La ingeniería de propiedades de masa (MpE) asegura que el sistema o elemento del sistema
tenga las propiedades de masa apropiadas para cumplir con los requisitos (SAWE). Las
propiedades de masa incluyen el peso, la ubicación del centro de gravedad, la inercia alrededor
del centro de gravedad y el producto de la inercia alrededor de un eje.
Típicamente, el tamaño inicial del sistema físico se deriva de otros requisitos, como la carga
mínima de pago, el peso operativo máximo o las restricciones de factor humano. Las
estimaciones de propiedades masivas se realizan en todas las etapas del ciclo de vida del
sistema en función de la información disponible en ese momento. Se lleva a cabo una
evaluación de riesgos, utilizando técnicas tales como análisis de incertidumbre o simulaciones
de Monte Carlo, para verificar que las propiedades de masa predichas del sistema cumplirán
los requisitos y que el sistema operará dentro de los límites de diseño. MpE se realiza al final
de la etapa de producción para garantizar a todas las partes que el sistema entregado cumple
con los requisitos y luego varias veces durante la etapa de utilización para garantizar la
seguridad del sistema, elemento del sistema u operador humano.
Una trampa en MpE es creer que las herramientas de modelado tridimensional pueden usarse
exclusivamente para estimar las propiedades de masa del sistema o elemento del sistema.
Esto es problemático porque (i) no todas las partes se modelan en el mismo programa y (ii) la
mayoría de las partes se modelan idealmente.
10.8 CONFIABILIDAD, DISPONIBILIDAD Y M ANTENIMIENTO
Para ser confiable, un sistema debe ser robusto; debe evitar los modos de falla incluso en
presencia de una amplia gama de condiciones que incluyen entornos hostiles, demandas
operacionales cambiantes y deterioro interno (Clausing y Frey, 2005). Por lo tanto, la
confiabilidad puede verse como el funcionamiento apropiado de un sistema durante su vida
esperada en toda la gama de condiciones experimentadas en el campo.
La ingeniería de confiabilidad se refiere a la disciplina de ingeniería especializada que aborda

la confiabilidad de un sistema durante su ciclo de vida total. Incluye aspectos relacionados
como disponibilidad y mantenimiento de un sistema. Por lo tanto, la ingeniería de confiabilidad
se usa a menudo como término colectivo para la disciplina de ingeniería relacionada con la
RAM de un sistema.
RAM son atributos o características importantes de un sistema dado. Sin embargo, la RAM no
debería verse como características, sino como requisitos no funcionales. Por lo tanto, es
esencial que los procesos de SE incluyan las actividades de RAM, seleccionadas, planificadas
y ejecutadas de manera integrada con otros procesos técnicos.
Las actividades de ingeniería de confiabilidad respaldan otros procesos SE de dos maneras.

En primer lugar, las actividades de ingeniería de confiabilidad deberían usarse para influir en el
diseño del sistema (por ejemplo, la arquitectura del sistema depende de los requisitos de
confiabilidad). En segundo lugar, las actividades de ingeniería de confiabilidad se deben usar
como parte de la verificación del sistema (por ejemplo, análisis del sistema o prueba del
sistema).
10.8.1 Confiabilidad
Tradicionalmente, la confiabilidad se ha definido como la probabilidad de que un elemento
desempeñe una función requerida sin fallar bajo las condiciones establecidas durante un
período de tiempo determinado.
Los objetivos de la ingeniería de confiabilidad, en orden de prioridad, son (O'Connor y Kleyner,

2012):
76
● Aplicar conocimientos de ingeniería y técnicas especializadas para prevenir o reducir la

probabilidad o frecuencia de fallas
● Identificar y corregir las causas de las fallas que ocurren, a pesar de los esfuerzos para
prevenirlas
● Determinar formas de enfrentar las fallas que ocurren, si sus causas no han sido
corregidas
● Aplicar métodos para estimar la confiabilidad probable de nuevos diseños y para
analizar datos de confiabilidad
10.8.2 Disponibilidad
La disponibilidad se define como la probabilidad de que un sistema, cuando se usa bajo las
condiciones establecidas, operará satisfactoriamente en cualquier momento según sea
necesario. Por lo tanto, la disponibilidad depende de la confiabilidad y la capacidad de
mantenimiento del sistema, así como del entorno de soporte durante las etapas de utilización y
soporte. Se puede expresar y definir como disponibilidad inherente, lograda u operativa
(Blanchard y Fabrycky, 2011):
● La disponibilidad inherente (Ai) se basa solo en la fiabilidad inherente y la capacidad de

mantenimiento del sistema.
● La disponibilidad lograda (Aa) es similar a la disponibilidad inherente, excepto que se
incluye el mantenimiento preventivo (es decir, programado).
● La disponibilidad operacional (Ao) supone un entorno operativo real y, por lo tanto,
incluye el tiempo de demora de la logística y el tiempo de demora administrativa.
10.8.3 Mantenibilidad
Un objetivo de la ingeniería de sistemas es diseñar y desarrollar un sistema que pueda
mantenerse de manera efectiva, segura, en el menor tiempo posible, al menor costo y con un
gasto mínimo de recursos de soporte sin afectar adversamente la misión de ese sistema. La
capacidad de mantenimiento es la capacidad de un sistema para mantenerse, mientras que el
mantenimiento constituye una serie de acciones que se deben tomar para restaurar o retener
un sistema en un estado operacional efectivo. La capacidad de mantenimiento debe ser
inherente o estar "integrada" en el diseño, mientras que el mantenimiento es el resultado del
diseño. La capacidad de mantenimiento se puede expresar en términos de tiempos de
mantenimiento, factores de frecuencia de mantenimiento, horas de mantenimiento de mano de
obra y costo de mantenimiento. El mantenimiento se puede dividir en mantenimiento correctivo
y mantenimiento preventivo.
10.9 INGENIERÍA DE RESILIENCIA
La resiliencia es la capacidad de prepararse y planificar, absorber o mitigar, recuperarse o

adaptarse con mayor éxito a los eventos adversos reales o potenciales.
Aunque esta definición puede aplicarse a la capacidad de recuperación de cualquier sistema

diseñado, incluidos los activos físicos y humanos, el trabajo inicial (Hollnagel et al., 2006) se
centró en la capacidad de recuperación de los sistemas organizacionales.
El propósito de diseñar un sistema resiliente es determinar la arquitectura y / u otras

características del sistema que anticiparán, sobrevivirán y se recuperarán de una interrupción o
interrupciones múltiples.
77
10.10 INGENIERÍA DE SEGURIDAD (SAFETY) DEL SISTEMA
La ingeniería de seguridad del sistema es un derivado aplicado de SE que se basa en los

fundamentos del buen pensamiento de sistemas y los aplica analíticamente a través de cada
una de las fases del ciclo de vida del sistema. El núcleo de la ingeniería de seguridad del
sistema es el análisis de cada uno de los requisitos, cada elemento del sistema y cada
comportamiento macro a micro dentro del contexto del sistema que se está desarrollando,
operando o sosteniendo para identificar y eliminar o controlar el riesgo potencial de seguridad.
El potencial de riesgo de seguridad se define como cualquier condición que produzca
condiciones no deseadas del sistema que dañe el sistema, dañe a los humanos involucrados
en las operaciones y soporte del sistema, o daños al medio ambiente.
El objetivo principal de la ingeniería de seguridad del sistema es influir en el diseño con los
requisitos relacionados a la seguridad para las etapas de desarrollo, producción, utilización,
soporte y retiro de un sistema seguro. Los beneficios de un sistema seguro son numerosos e
incluyen, entre otros, la reducción del riesgo asociado con el costo, el cronograma, la
efectividad operativa, la disponibilidad del sistema y la responsabilidad legal.
10.11 INGENIERÍA DE SEGURIDAD (SECURITY) DEL SISTEMA
La ingeniería de seguridad del sistema se centra en garantizar que un sistema pueda funcionar
en condiciones disruptivas asociadas con el mal uso y el comportamiento malicioso.
Implica una aplicación disciplinada de los principios SE en el análisis de amenazas y

vulnerabilidades a los sistemas y la evaluación y mitigación del riesgo para los activos de
información del sistema durante su ciclo de vida. Aplica una combinación de tecnología,
principios y prácticas de gestión, y reglas operativas para garantizar que haya suficientes
protecciones disponibles para el sistema en todo momento.
Las fuentes de posibles condiciones disruptivas (amenazas) son muchas y variadas. Pueden
ser naturales (por ejemplo, clima) o hechos por el hombre. Pueden emanar de fuentes externas
(por ejemplo, interrupciones políticas o de energía) o pueden ser causadas por fuerzas internas
(por ejemplo, usuario o sistemas de soporte). Una interrupción puede ser involuntaria o
intencional (maliciosa) en la naturaleza. Las capacidades de seguridad, ya sean
implementadas a través del diseño, la política o la práctica, deben ser utilizables desde la
perspectiva del usuario.
Para ser eficaz, la ingeniería de seguridad del sistema se aplica durante todo el ciclo de vida
del sistema.
10.12 ANÁLISIS DE NECESIDADES DE CAPACITACIÓN
Los análisis de las necesidades de capacitación respaldan el desarrollo de productos y

procesos para la capacitación de los usuarios, los administradores y el personal de apoyo de
un sistema. El análisis de capacitación incluye el desarrollo de capacidades y competencias de
personal para llevar a cabo tareas en cualquier punto del ciclo de vida del sistema hasta el nivel
que se les asigna. Un análisis de capacitación efectivo comienza con una comprensión
exhaustiva de los documentos conceptuales y los requisitos para el SOI. Los objetivos de
aprendizaje determinan el diseño y desarrollo de los módulos de capacitación y sus medios de
entrega.
Las consideraciones importantes en el diseño de la capacitación incluyen quién, qué, en qué

condiciones, qué tan bien debe capacitarse a cada usuario y qué capacitación cumplirá los
objetivos.
78
10.13 ANÁLISIS DE UTILIZACIÓN / INTEGRACIÓN DE SISTEMAS HUMANOS
La integración de sistemas humanos (HSI) es el proceso interdisciplinario técnico y de gestión

para integrar las consideraciones humanas dentro y a través de todos los elementos del
sistema. HSI se enfoca en lo humano, un elemento integral de cada sistema, a lo largo del ciclo
de vida del sistema. Es un facilitador esencial para la práctica SE ya que promueve un enfoque
de "sistema total" que incluye humanos, tecnología (por ejemplo, hardware, software), el
contexto operacional y las interfaces necesarias entre los elementos para hacer que todos
trabajen en armonía (Bias y Mayhew, 1994; Blanchard y Fabrycky, 2011; Booher, 2003.
El objetivo principal de HSI es garantizar que las capacidades y limitaciones humanas se traten
como elementos críticos del sistema, independientemente de si los humanos en el sistema
operan como individuos, tripulaciones, equipos, unidades u organizaciones. Es importante
reconocer que los humanos fuera del sistema pueden verse afectados por su operación.
La aplicación integral de HSI para el desarrollo, diseño y adquisición del sistema tiene como
objetivo optimizar el rendimiento total del sistema (p. Ej., Humanos, hardware y software) al
mismo tiempo que acomoda las características de la población que usará, operará, mantendrá
y apoyará la sistema y también apoyar los esfuerzos para reducir el LCC.
Un método clave de HSI son los estudios y análisis de comercio. Los análisis de HSI,
especialmente los análisis de requisitos que incluyen cuestiones e implicaciones humanas, a
menudo dan lugar a ideas que de otro modo no se verían. Los estudios comerciales que
incluyen cuestiones relacionadas con los seres humanos son fundamentales para determinar el
diseño que es el más eficaz, eficiente, adecuado (incluido el útil y comprensible), utilizable,
seguro y asequible.
HSI ayuda a los ingenieros de sistemas a concentrarse en los costos a largo plazo, ya que gran
parte de ese costo está directamente relacionado con las áreas de elementos humanos.
10.14 INGENIERÍA DE VALORES (VE)
VE, gestión de valor (VM) y análisis de valor (VA) son todos términos que pertenecen a la
aplicación del proceso de VE (Bolton et al., 2008; Salvendy, 1982; SAvE, 2009).
VE utiliza un proceso sistemático (por ejemplo, un plan de trabajo formal), facilitadores / jefes
de equipo certificados por VE y un enfoque de equipo multidisciplinario para identificar y
evaluar soluciones a problemas complejos en el ciclo de vida de un proyecto, proceso o
sistema. El proceso de VE utiliza varias técnicas estándar de resolución de problemas / toma
de decisiones en un esfuerzo organizado dirigido a analizar de forma independiente las
funciones de programas, proyectos, organizaciones, procesos, sistemas, equipos,
instalaciones, servicios y suministros. El objetivo es lograr las funciones esenciales en el LCC
más bajo compatible con el rendimiento requerido, la confiabilidad, la disponibilidad, la calidad
y la seguridad. VE no es una actividad de reducción de costos sino un método orientado a las
funciones para mejorar el valor de un producto. No hay límite para el campo en el que se puede
aplicar VE.
El objetivo de realizar VE es mejorar el valor económico de un proyecto, producto o proceso

revisando sus elementos para lograr lo siguiente:
● Lograr las funciones y requisitos esenciales

● Menor LCC total (recursos)
● Alcanzar el rendimiento requerido, seguridad, confiabilidad, calidad, etc.
● Cumplir los objetivos del cronograma
79
El valor se define como un rendimiento justo o su equivalente en bienes, servicios o dinero por
algo intercambiado. En otras palabras, el valor se basa en "lo que obtienes" en relación con "lo
que cuesta". Está representado por la relación:
Función / costo de valor
La función se mide según los requisitos del interesado. El costo se calcula en los materiales,
mano de obra, precio, tiempo, etc. necesarios para cumplir esa función.
De acuerdo con la Sociedad de Ingenieros de Valor Americanos (SAvE) International, para

calificar como un estudio de valor, se deben cumplir las siguientes condiciones:
● El equipo de estudio de valores sigue un plan de trabajo de vE organizado de seis

fases (consulte el siguiente texto) y por análisis de función de formularios.
● El equipo de estudio de valor es un grupo multidisciplinario, elegido en función de su
experiencia.
● El líder del equipo de estudio de valor (es decir, el facilitador) está capacitado en la
metodología de valor.
80

Resumen SEBoK V2 30-07-2018

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Resumen SEBoK V2 30-07-2018

Загружено:

Авторское право:

Доступные форматы

RESUMEN

5.4 Proceso de gestión de riesgos 46

9.1.12 Modelo y Métricas basadas en Simulación 65

CAPÍTULO 2: CONCEPTOS DE INGENIERÍA EN

En este capítulo se verán brevemente los principales conceptos referidos a la Ingeniería en

Conjunto integrado de elementos, subsistemas o ensambles que logran un objetivo definido.

2.2 JERARQUÍA DENTRO DE UN SISTEMA

2.4 SISTEMA DE SISTEMAS (SOS)

Es un sistema de interés (SOI) cuyos elementos son operados/gestionados

La mejor manera de entender un sistema complejo es romperlo recursivamente en partes

Los siguientes desafíos influyen en la ingeniería de un sistema de sistemas:

● Liderazgo: Esta cuestión del liderazgo se experimenta cuando la falta de control

● Perspectiva de los sistemas constituidos: Los SoS están compuestos típicamente,

● Capacidades y requerimientos: Típicamente cada Sistema múltiple del SoS presenta

● Autonomía, interdependencia y emergencia: La independencia de los sistemas

● Testeo, validación y aprendizaje: Puede ser muy difícil evaluar el nivel de

2.5 SISTEMAS DE HABILITACIÓN

2.6 DEFINICIÓN DE INGENIERÍA DE SISTEMAS

Según INCOSE, la Ingeniería en Sistemas es una actividad interdisciplinaria que busca la

2.7 ORIGEN Y EVOLUCIÓN DE LA SE

En 1990 se crea el Consejo Nacional de Ingeniería en Sistemas (NCOSE), tomando carácter

2.8 APLICACIÓN Y VALOR DE LA INGENIERÍA EN SISTEMAS

2.9 CIENCIA DE LOS SISTEMAS Y EL PENSAMIENTO CIENTÍFICO

2.9.1 Ciencia de los sistemas

2.9.2 Pensamiento sistémico (System Thinking)

La aplicación práctica del pensamiento sistémico a menudo emplea el uso de representaciones

2.10 Liderazgo de la Ingeniería de Sistemas

● Reconocer que es lo que genera comportamiento en la estructura del sistema

Para ayudar a realizar sistemas exitosos, el ingeniero de sistemas admite un conjunto de

2.11 DESARROLLO PROFESIONAL DE LA INGENIERÍA EN SISTEMAS

CAPÍTULO 3: CICLO DE VIDA DE UN SISTEMA

3.3 PUNTOS DE DECISIÓN (KPD)

● Asegurar que la elaboración de las bases técnicas y comerciales son aceptables. De

3.4 ETAPAS DEL CICLO DE VIDA

● Concepto: Define el espacio del problema, caracterizando una solución viable,

Ciclo de vida de un instrumento satelital:

3.5 MODELOS DE CICLO DE VIDA

específico como la evolución del sistema a través de una serie de representaciones

El lado derecho de la V representa la integración de las piezas y su verificación.

Un atributo clave de este modelo es el tiempo y la madurez del proceso se mueve de

3.6 CRITERIO DE SELECCIÓN DE PROCESOS

El pensamiento sistémico y la SE asegura que el diseño del sistema se adapte apropiadamente

CAPÍTULO 4: PROCESO TÉCNICO

1. Proceso de análisis de misión o de negocio: Se definen los requerimientos de

8. Proceso de integración: La integración consiste de un progresivo ensamble de los

A continuación se procederá a presentar de manera más detallada cada una de estas

4.1 PROCESO DE ANÁLISIS DE MISIÓN O DE NEGOCIO

- Plan estratégico de la Organización

- Preparar el análisis de la misión o del negocio: establecer la estrategia del análisis

- Caracterizar el espacio de soluciones: se debe nominar los actores que deberán

4.2 PROCESO DE DEFINICIÓN DE LOS REQUERIMIENTOS Y NECESIDADES DE LOS INTERESADOS

- Prepararse para la definición de necesidades y requerimientos de los

actores que pueden influir en el sistema. También se determinan los

4.3 PROCESO DE DEFINICIÓN DE LOS REQUERIMIENTOS DEL SISTEMA

Un buen requerimiento debe tener las siguientes características:

- Preparar la definición de requerimientos del sistema: se define la arquitectura,

4.4 PROCESO DE DEFINICIÓN DE LA ARQUITECTURA

- Preparar la definición de la arquitectura: identificar y analizar las condiciones del

4.5 PROCESO DE DEFINICIÒN DEL DISEÑO

Las características de diseño incluyen las dimensiones, forma, material y la estructura de

4.6 PROCESO DE ANÁLISIS DEL SISTEMA

- Preparar el análisis del sistema: Se define el alcance, el tipo, objetivos y nivel de