IDST

E.T.S.
INGENIERA DE TELECOMUNICACIN
UNIVERSIDAD DE MLAGA
MLAGA
INGENIERA DE DESARROLLO
DE SISTEMAS DE
TELECOMUNICACIN
5 CURSO
INGENIERA DE DESARROLLO DE SISTEMAS DE TELECOMUNICACIN
TEMARIO
TEMA 1:
INTRODUCCIN.
TEMA 2:
SISTEMAS COMPLEJOS Y SU REPRESENTACIN.

- Sistemas.
- Estructuras.
- Interfaces.
TEMA 3:
CARACTERSTICAS DE LOS SISTEMAS.

-
TEMA 4:
METODOLOGA DEL PROCESO DE DESARROLLO.

-
TEMA 5:
Procesos de Explotacin.
Caractersticas generales.
Caractersticas especiales.
Fiabilidad.
Mantenibilidad.
Definicin.
Anlisis.
Diseo.
Verificacin.
Control del Diseo.
Gestin de Configuracin.
SISTEMAS DE CALIDAD.
- Normalizacin de la Calidad.
- Modelos concurrentes.
- Modelos de madurez.
PGINA 2
PGINA 3
Tema 1: Introduccin
-
Concepto de Sistema.
Concepto de ingeniera de Sistemas.
El proceso de desarrollo.
El ciclo de vida.
Concepto de Sistema.
Un Sistema es un conjunto de cosas que, ordenadamente relacionadas entre s,
contribuye a determinados objetivos.
Un Sistema es algo compuesto por elementos. Los elementos son partes que
componen el Sistema. Un elemento vendr definido por su funcin, lo que el elemento
es capaz de hacer. Los elementos relacionados y el Sistema tienen una funcin global o
un comportamiento externo:
Por ejemplo, un filtro tiene como funcin filtrar y est compuesto por
resistencias, capacidades, ... Podemos decir su funcin sin decir de lo que est hecho.
Un Sistema nos servir para abordar la complejidad, es decir, describe o
representa algo complejo. Habr que ver esa complejidad y decidir qu partes
componen el Sistema: divisin. Nos servir el concepto de Sistema para describir algo
que ya existe: anlisis y sntesis. El anlisis describe la realidad compleja de arriba
abajo; mientras que la sntesis crea algo que no existe, para que cumpla un objetivo.
Tenemos que hacer el proceso de divisin en los dos casos:
PGINA 4
Hay divisiones ms tiles que otras. Por ejemplo, las que hacen que el nmero
de elementos sean pequeos, sus interacciones dbiles. As que, el concepto de Sistema
nos ayuda a manejar la complejidad y a volver a dividir los elementos.
Concepto de ingeniera de Sistemas.

Tambin lo llaman: ingeniera, ingeniera de Sistemas complejos, ingeniera de
desarrollo de Sistemas o arquitectura de Sistemas o diseo de Sistemas.
La ingeniera es el arte de disear y optimizar Sistemas partiendo de una
necesidad y terminando con una especificacin de cada uno de sus elementos (lo que
tiene que hacer cada elemento).
Las caractersticas de esta disciplina:
-
es una disciplina tcnica.

interdisciplinaria comn a muchas ingenieras.
generalmente, se emplean para problemas de gran escala.
uso de la abstraccin puede ser una dificultad.
conjunto de mtodos y reglas normalmente, basado en la experiencia.
El proceso de desarrollo.
El desarrollo ser ese conjunto de actividades que permite pasar de una
necesidad a un Sistema:
El proyecto es una particularizacin de esa actividad de desarrollo, es un caso

particular.
El proceso de desarrollo es algo complejo, por lo que se le aplica el concepto de
Sistema: se dividir ese proyecto (con una funcin global), ese Sistema. Esta divisin se
puede hacer de muchas formas, veremos la ms sencilla, pero con muchos
inconvenientes.
PGINA 5
El modelo ser secuencial:
Cada proceso utiliza como entrada la salida del anterior e independizamos cada
trozo. Para que sea fcil, se pone pocos trozos pero bien definidos y relacionados con el
de arriba y el de abajo. Los problemas se solucionarn con la interactividad.
Se suele usar cuatro o cinco fases:
Las funciones de cada uno de estos elementos:

-
definicin define los objetivos del proyecto. Se habla de pasar de la necesidad a

los requisitos.
anlisis identificar un Sistema que cumple con esos requisitos. Pasamos de los
requisitos a las especificaciones del Sistema (suelen ser de alto nivel).
diseo divisiones sucesivas de elementos hasta elementos manejables. Pasamos
de las especificaciones del Sistema a especificaciones de elementos.
construccin construye el sistema a partir de documentos. Construir es obtener
una o varias realizaciones. Pasamos de las especificaciones al sistema real.
verificacin comprobar que el sistema cumple las especificaciones. Casi nunca es
posible una verificacin completa.
Los problemas de este proceso es la propagacin de errores.
DEFINICIN.
La definicin la hace el ingeniero (responsable), pero est el cliente. El cliente
es quien conoce, concreta y define la necesidad (empresa, ...); el que tiene la
informacin.
Sus caractersticas son:
PGINA 6
se define el servicio a ofrecer, pero no el Sistema (vendr despus).

habr restricciones (dadas o las hacemos).
no es ambigua. La ambigedad estar al principio y la debemos eliminar aqu.
debe tener solucin.
debe ser posible verificar los requisitos.
Hay que ser pesimista: lo que no se pida, no se hace para optimizar. Si hay algo
ambiguo, se supondr que se entender al revs. Dejar claro las cosas, vamos por fases.
ANLISIS.
Los requisitos son las especificaciones de los Sistemas. Los procesos que
haremos son:
-
identificar las alternativas de tecnologa, divisin y asignacin de requisitos

elementos.
- decidir tecnologa optimizar. A veces, el criterio de optimizacin vendr dado.
- especificar: (es como optimizaremos)
Sistema conjunto de elementos y conjunto de especificaciones. Un
nivel o varios.
cmo desarrollar plan de desarrollo.
cmo probar plan de pruebas. Es esta fase donde se decide qu
verificaciones hay que hacer.
cmo hacer la explotacin es el uso de realizaciones del Sistema:
- cmo usar.
- cmo mantener los sistemas se irn degradando.
DISEO.
Iremos partiendo en elementos ms pequeos (hasta que lo pueda hacer una
persona) y sus especificaciones. Al final, tenemos un conjunto de especificaciones de
elementos: cmo realizar un elemento que haga algo. Tambin, se suele hacer la
documentacin adicional para cada elemento que se disee:
-
planes de pruebas probar.

manuales de uso usar.
mantenimiento mantener.
La informacin que sale debe ser capaz de resolver cualquier duda ajena al
proceso.
CONSTRUCCIN.
Las actividades que se realizarn son :
-
diseo (no complejo).

compras.
fabricar.
pruebas cada elemento por separado.
PGINA 7
integracin los elementos fabricados y comprobados; se juntan y prueban los

elementos de mayor nivel hasta el sistema, que no se prueba.
Se dice que estas actividades no son de ingeniera de sistemas. Hay poca

actividad de diseo, de toma de decisin. Son actividades con poca incertidumbre,
fcilmente planificable.
VERIFICACIN.
Se suele decir que cumpla los requisitos, normalmente. La verificacin requiere
de herramientas de prueba (otros sistemas que se enfrentan al sistema a verificar). Los
sistemas complejos tendr verificaciones complejas e incompletas. A veces hay que
disear esas herramientas de prueba; hay que preverlo en la fase de anlisis.
El ciclo de vida del proyecto.
Son todos los procesos ordenados secuencialmente. Despus de esto est la
explotacin.
Explotacin del Sistema.

Las actividades que se hacen son:
-
fabricacin hace realizaciones (sistemas).

instalacin actividad que hay que hacer
(particularizacin).
con
un
sistema
fabricado
------- a partir de aqu, actividades que se hacen a lo largo de la vida del sistema --------
operacin control humano necesario para que un sistema artificial ofrezca el

servicio.
- mantenimiento es la funcin que permite mantener el ofrecimiento del servicio.
Hace falta, ya que los sistemas con el tiempo se degradan. Hay un mantenimiento
asociado al sistema (conocido) y otro al Sistema. Este ltimo es quizs ms
importante, ya que mantiene el Sistema al da.
- soporte es lo dems que hace falta: entradas, llevarle combustible, ...
PGINA 8
Se suele llamar ciclo de vida del Sistema al tiempo que va desde la necesidad
hasta que se desecha (fin de la explotacin):
Hay dos desechos: del Sistema y de los sistemas (realizaciones). Los ciclos de
vida del Sistema pueden variar mucho: largo ciclo de vida del proyecto y corto de
explotacin o, como es general, el ciclo de vida del proyecto ms corto que la
explotacin (infraestructura civil).
Clasificacin de proyectos.
Lo podemos clasificar segn el tipo de usuario; el usuario es el beneficiario del
servicio. Habr dos tipos de proyectos:
-
a medida (llave en mano) el usuario es alguien conocido y es quien promueve el

proyecto.
- fabricacin masiva se hacen muchas realizaciones. Los usuarios son desconocidos
y eso puede ser un problema; por eso es importante que el Cliente sea capaz de definir
la necesidad, por eso ser el marketing quien defina la necesidad y haga de promotor.
usuario
promotor
nmero de realizaciones
Cliente
a medida
conocido
usuario
pocas(*) (una)
usuario
fabricacin masiva
desconocidos
Marketing
muchas
Marketing
en general, a veces una (carretera) o muchas (sucursal bancaria).
(*)
PGINA 9
Tema 2: Sistemas complejos y su realizacin.

-
Sistema.
Estructura.
Interfaces.
Sistema.
Es un concepto mediante el cul describimos un artefacto compuesto por cosas
ms pequeas que, relacionadas entre s, cooperan y satisfacen una necesidad. La idea
es: divide y vencers. Habr que hacer dos procesos mentales para usar el concepto de
Sistema para problemas complejos:
-
divisin (en partes).

abstraccin.
Lo veremos con ejemplos.
DIVISIN (EN PARTES).

Proceso por el cual pasamos de una realidad compleja (comportamiento externo)
a un conjunto de elementos e interacciones (Sistema). Veamos un ejemplo:
fotocopia 33.1 arriba
Cada elemento tiene una funcin representada por un smbolo. Para
describirlo usaremos menos elementos. Decimos su funcin con una palabra (si
es posible): medida de tensin alterna. Detallando ms, se puede decir que mide
el valor eficaz de una tensin alterna y lo presenta visualmente. Si se sale de los
lmites, nos avisa una alarma. Este es su comportamiento exterior.
Para concretar ms, divido en partes funcionales, las mnimas necesarias.
Agruparemos elementos que cooperen en una determinada funcin.
fotocopia 33.1 abajo
Vemos que lo dividimos en cuatro elementos, con interaccin entre ellos,
sencillos. Se describe la funcin de cada elemento fcilmente, sin trminos
tecnolgicos sino funcionales. Las interacciones son sencillas: representaciones
del interfaz a medir.
Se pueden hacer otras descripciones de las interacciones, viendo las
interacciones externas que hay (aparte de las de entrada y salida) y de las
internas. An as, falta los interfaces para el suministro de la energa elctrica.
Debe describirse con pocas palabras las funciones y las interacciones,
procurando que sea mnimo el nmero de interacciones y de elementos.
PGINA 10
La divisin no es nica, por lo que hay que buscar la ms adecuada. Lo general

es usar niveles jerrquicos de descripcin y usar la abstraccin.
El objetivo es describir algo complejo. Segn esto, nos interesa una divisin u
otra, segn para qu. No debemos explicar ms cosas de las necesarias ya que
confunden.
En general, vamos a tener que usar niveles de complejidad. Puede ser un
elemento de un Sistema superior. Es el concepto de Sistema a muchos niveles.
fotocopia 33.1 vuelta
A cada elemento del nivel jerrquico se le suele dar un nombre. Para nosotros,
un Sistema es un conjunto de elementos. Si entramos en un elemento, ahora es l el
Sistema. Si usamos muchos niveles jerrquicos, al bajar los elementos sern ms
sencillos. La gracia ser que aunque estemos en alto nivel, aunque sea complejo, no
debe ser compleja su descripcin. Esto es, no por subir de nivel, la descripcin de la
funcin ha de ser ms complicada.
El uso de la abstraccin es fundamental para hacer todo esto. La abstraccin es
un proceso mental por el cul filtramos los detalles y nos quedamos con la parte de la
descripcin que nos interesa (elegimos las palabras representativas de la funcin).
Adems, la abstraccin permite representar Sistemas distintos pero que
comparten propiedades. La propiedad que en esta asignatura abstraeremos es la funcin
(lo que hace), evitando decir lo que es o de qu se compone. A cambio, dejaremos ver
otras cosas para entender el Sistema a ese nivel.
Veamos algunos ejemplos de Sistemas. Primero haremos una descripcin no
abstracta y luego abstracta. Con el segundo ejemplo haremos justo al revs.
EJEMPLO DE ABSTRACCIN 1: SISTEMA DE SUMINISTRO DE AGUA.
Satisface la necesidad de agua teniendo un depsito. Usaremos una bomba que
d agua a la casa.
Vamos a intentar mejorar el Sistema. Los problemas que tiene es que se

desperdicia, a veces, agua y se corre riesgo de no tener agua cuando queramos. As que
completamos el Sistema con un aljibe, como vemos en la figura (inicialmente no
PGINA 11
estaba). Mejoramos la funcin del Sistema, ya que somos capaces de dar ms agua que
el caudal de la bomba y no desperdiciamos agua. Tambin subsanamos el fallo de
suministro de agua.
Una descripcin ms abstracta del ejemplo sera: el Sistema es un Sistema de
suministro (es la funcin) con dos interfaces externos: demanda y suministro.
Tiene el mismo problema: alto riesgo de fallo y desperdicio de agua. Aadimos

al Sistema la funcin de almacenamiento que es:
El almacn, cuando se le pide, entrega para aumentar el contenido. Cuando el

contenido llega a la mxima capacidad, se corta el suministro (flotador del aljibe). Pide
si no est lleno. El sistema global sera:
Sera un Sistema de suministro con almacenamiento; hemos mejorado el servicio

al desacoplar la demanda del suministro.
La ventaja que la abstraccin tiene es que puedo emplear esta descripcin para el
suministro de agua o para lo que sea: flujo de caja, sistema de alimentacin
ininterrumpida, desacoplo de circuitos integrados, ajuste de velocidad en un sistema de
transmisin digital,...
sistema
suministro de agua
alimentacin ininterrumpida
flujo de caja
desacoplo de C.I.s
ajuste de velocidad (Tx)
elemento real
aljibe
batera
cuenta bancaria
condensador
buffer de memoria
elemento funcional
almacenamiento
almacenamiento
almacenamiento
almacenamiento
almacenamiento
PGINA 12
El elemento funcional permite hablar en un lenguaje nico (abstracto), aunque

sea ms difcil.
EJEMPLO DE ABSTRACCIN 2: RED TRONCAL.
Ahora presentamos un modelo abstracto y luego particularizaremos para varios
casos.
La funcin que hace este Sistema es el transporte. El Sistema consiste en:
Los accesos estarn enlazados con terminales. En la descripcin interesar dar la

funcin de los elementos. El terminal genera y consume los objetos que se transportan.
El enlace transporta un objeto de un sitio a otro fijo. El tronco es una agregacin de
enlaces capaz de transportar varios objetos simultneamente; el tronco hace la funcin
de multiplexacin. Los nodos hacen la funcin de conmutacin, esto es, intercambian
objetos de un enlace a otro.
Podemos hablar de funciones del Sistema. Por ejemplo, el encaminamiento
consiste en elegir un camino de un terminal a otro a travs de la red troncal; habr que
decidir qu troncos se utilizan y cmo hacer la conmutacin a los nodos.
Concretando, puede servir para: sistema de telefona de rea extensa, transporte
de agua, electricidad, gas, ferrocarril, ... Cualquier Sistema de transporte de rea
extensa.
En telecomunicacin, los nombres de los elementos se mantienen; en transporte
de energa elctrico, a los nodos se les llama contadores, ...
Volviendo a la abstraccin, hay propiedades del Sistema como la capacidad, que
est asociada a las prestaciones del servicio que ofrece. Tambin se habla de la
capacidad de acceso al nodo, no slo a los elementos por segundo.
Vemos tres ejemplo de Sistemas conocidos:
-
la calculadora de programa almacenado (John von Neumann, 1.945) la primera

descripcin que hago es la de usuario. Su funcin :
es ejecutar automticamente algoritmos.
poder cambiar fcilmente el algoritmo.
PGINA 13
De momento slo nos interesa lo que hace; al usuario hay que decirle cmo
funciona los interfaces, sin necesidad de que sepa lo que hay dentro:
algoritmo se le muestra como una secuencia de instruccin (es una
operacin elemental). Necesitan un cdigo (representacin de
operaciones elementales).
Esto es una representacin para el usuario. Ahora bajamos un poco ms. La
solucin en cuanto divisin en parte es:
Cada nombre nos dice lo que hace. Los elementos estn relacionados con las
interacciones que vemos. La idea original se sigue usando, aunque con
modificaciones. El gran invento es que en la memoria se almacenan los datos de
entrada y salida, variables temporales y el algoritmo.
-
el Sistema de telefona es el Sistema mundial. Tiene cuatro grandes funciones:

transmisin, conmutacin, sealizacin y gestin. Primero hacemos la descripcin de
la funcin con un nombre y luego con unas cuantas lneas. Es importante el manejo
de lenguaje abstracto, en funcin de hacia quien vaya dirigido. Este ejemplo es muy
complejo, por eso es tan abstracto.
fotocopia 33.2 vuelta abajo
la interconexin de sistemas abiertos (1.977) La estructura es sencilla.

fotocopia 33.2 vuelta arriba
Estructura.
-
concepto, representacin.
estructuras parciales.
vistas
estructuras modulares configurables.
PGINA 14
Concepto de estructura.
La estructura es la distribucin y orden de las partes de un todo. Para nuestro
lenguaje, al todo le llamaremos Sistema y a las partes, elementos.
La estructura tambin nos dice con quin se relacionan los elementos. En
definitiva: el orden. Adems, hacen falta las funciones de los elementos. Pero
estrictamente, la estructura equivale al orden (sin funciones ni interacciones).
Para representarla, se puede usar matrices de adyacencia, o definirlo como un
conjunto de elementos (A = {a i}). La forma ms habitual de representar la estructura es
mediante grafos (orientados).
El orden (estructura) determina la funcin global del Sistema.
Algunos ejemplos son:
-
ismeros de qumica inorgnica mismos elementos pero cambiando el orden en

que se relacionan.
- lenguaje una frase cambia de significado segn el orden de las palabras.
- plan de estudios hay un orden de asignaturas, pero se puede cambiar.
- el orden no se aplica slo a cosas, sino tambin a personas un grupo de personas
que realicen cierta tarea, dentro de una empresa.
Estructuras parciales.
Si el Sistema es muy complejo y queremos representar la estructura, podemos
hacer estructuras parciales o vistas, que son ms sencillas.
A veces, es mejor no considerar todas las interacciones entre los elementos. As,
slo cogemos una clase de interacciones.
Vemos que podemos considerar distintas estructuras, segn la interaccin
en la que nos fijemos:
-
arriba representacin de seales.

abajo alimentacin.
Hay muchas ms interacciones que podemos considerar: transferencia de calor,

fiabilidad, conexionado, fsica, ... Pero no tiene sentido representar todas las clases de
interacciones a la vez.
Hemos hablado antes de fiabilidad: un elemento falla cuando no cumple su
funcin. Todos los elementos llegan a fallar en algn momento, debido a la
degradacin. En este estado de fallo de un elemento, no tiene porqu fallar todo el
Sistema.
PGINA 15

Vemos el diagrama lgico de fallos.
El estado de fallo se representa por un interruptor. Si un elemento falla, en este
ejemplo, no se cumple la funcin global. Por tanto, los fallos tambin hay que
considerarlos en las estructuras.
Vistas.
Son representaciones parciales del Sistema. Recordemos que cada
representacin tena los mismos elementos en distintos grupos. Las vistas tienen
distintos elementos, que dan lugar a distintas estructuras, segn el objetivo.
Habitualmente, el diseador no verifica.

Cada persona o grupo quiere una representacin (vista) distinta del Sistema.
Veamos para que sirven unas vistas u otras:
-
vista de usuario.
vista funcional.
vista real.
vista producto.
Cada trabajador usa las vistas (una o todas) que le interesa:
a) vista de usuario se considera el comportamiento exterior, define la interaccin del

Sistema con el usuario. Sirve para:
- disear el Sistema es casi la especificacin.
- definir.
- verificar.
b) vista funcional se ve el Sistema como elemento que interacciona. Se utiliza una
divisin en partes exclusivamente funcional. Los elementos hacen funciones
distintas no hay funciones repetidas.
No se hace cuantificacin ni prestaciones (capacidad, velocidad, consumo, ...).
Hay varios niveles de descripcin funcional, cada uno de ellos es un Sistema con sus
funciones y sus relaciones. Esto sirve para:
- organizacin eficiente del trabajo.
- asegurar el cumplimiento de la funcionalidad.
- facilitar el mantenimiento del Sistema.
PGINA 16
c) vista real no es del Sistema global, sino de elementos relacionados. No es del todo
funcional puede haber repeticin de funciones y agregacin.
La agregacin se refiere a que en la vista funcional se separaban en las partes
que tuvieran, poco que ver. Pero ahora se puede separar donde sea.
- no del todo funcional.
- puede hablar:
agregacin funciones compartir recursos.
repeticin.
La repeticin se hace por varias razones:
- distribucin geogrfica.
- prestaciones por acumulacin. A veces, la tecnologa actual no es capaz
de ofrecer las prestaciones que nos piden, as que repetimos funciones
iguales para alcanzar ms prestaciones.
- escalabilidad poder tener Sistemas con distintas prestaciones y
distintos precios.
- tolerancia a fallos si uno falla, otro elemento asume su funcin.
La vista real sirve para ver si se cumple el conjunto de prestaciones, un
ofrecimiento de objetivos pero cuantificado, por objetivo de fiabilidad, econmico.
d) vista de producto el Sistema es considerado como un conjunto de elementos
fsicos a ensamblar; el objetivo es la construccin. La funcionalidad no importa
demasiado, sino la combinacin de elementos: cules son, costes, ... Lo importante es,
en esta vista:
- componentes.
- posibles configuraciones distintas combinaciones de los elementos.
La vista de producto est relacionado con la explotacin: fabricacin,
mantenimiento, ... Generalmente usaremos la palabra configuracin para otra cosa
Veamos algunos ejemplos:
EJEMPLO 1: RED DE TELECOMUNICACIN.
Est formado por nodos, troncos y enlaces. Para cumplir con los objetivos hay
otras posibilidades.
fotocopia 33.3 vuelta abajo.
No es una vista funcional, es la vista real. Hay propiedades del Sistema
que dependen de esta vista: la capacidad, la conectividad y la tolerancia a fallos.
Un fabricante que construye conmutadores (C) y troncos de transmisin
(T), no le importa esta vista. Esta vista le interesa al proveedor. Al fabricante le
interesa la vista funcional (esta vista la vemos abajo).
La vista funcional servir en el diseo: funcin del conmutador (C) y
funcin de multiplexacin (T). Hay funciones comunes, como la alimentacin.
PGINA 17
El diseador podr hacer su trabajo. Lo importante es no tener en cuenta todas

las vistas a la vez.
Estructura modulares configurables.
MDULO pieza o conjunto de piezas que se repite en una construccin para hacerla
ms fcil, regular o econmica.
SISTEMA MODULAR el que usa mdulos. Consigue funciones o prestaciones por
repeticin de elementos iguales. Por ejemplo: ladrillos, construccin que es distinto
de ensamblaje.
SISTEMA CONFIGURABLE el que admite distintas estructuras con los mismos elementos
permitiendo obtener distintas funcionalidades (estructura Funcin).
La configurabilidad puede tener:
-
estructura fija Sistema que al cambiar la estructura no cumple la funcin

(televisin).
- configurables Sistema donde los elementos pueden tener distintas
configuraciones; los elementos pueden estar o no estar.
- re configurables Sistema que admite diferentes estructuras (diferentes
funciones), que puede cambiar de una a otra sin dejar de prestar servicios. Se dice que
el Sistema puede estar en distintos estados. Por cambiar de estructura, no tiene porqu
cambiar de servicio. Ese cambio de estado se puede hacer por rdenes o por re configuracin autnoma.
Los objetivos son:
-
facilidad y economa de fabricacin.

flexibilidad de la funcionalidad.
escalabilidad de las prestaciones. Se consigue con repeticin.
tolerancia a fallos.
EJEMPLO: MUEBLES DE CASA.

Se separa la fabricacin de mdulos de la instalacin. Se consigue que sea barato
y fcil, siendo un sistema a medida.
fotocopia 33.3 vuelta arriba.
PGINA 18
La particularizacin disea la vista real adaptada a una necesidad concreta. La

particularizacin necesita de la vista de producto, es decir, las posibles configuraciones
(vista reales que podemos tener).
EJEMPLO: BUCLE DE DISTRIBUCIN DE ENERGA.
Es una estructura reconfigurable.
As es como se conectan los usuarios para la toma de energa.

? Si se rompe aqu, qu pasa? Vemos como cambian los sentidos de transferencia
de la energa:
Vemos que cambian automticamente el sentido de distribucin de la energa

el sistema es reconfigurable cambia su estructura de transferencia de energa.
PGINA 19
Interfaces.
Concepto de interfaces.
Es una representacin de la interaccin entre dos elementos, que normalmente
consiste en el intercambio de algo material.
EXTREMO DEL INTERFAZ elementos que interaccionan. Si tienen la misma

funcionalidad interfaz simtrico.
Al hacer la divisin en partes de un proyecto, hay que hacer:
-
asignar funciones elementos

definir los interfaces
disear los elementos
Los ingenieros de Sistemas se encargan de asignar funciones y definir los

interfaces, mientras que los diseadores se encargan de los elementos.
Es ms importante definir los interfaces detalladamente que asignar funciones
para crear elementos. Es muy importante disear los interfaces con mucho nivel de
detalle!! Posteriormente, los interfaces no se podrn cambiar, o ser muy difcil hacerlo.
El interfaz va de transferencia selectiva.
En el interfaz se intercambia:
-
seal / informacin.
materiales fsicos (aire, agua, ...).
energa elctrica.
calor.
fuerza / movimiento.
fotocopia 33.4
Nos fijamos en el interfaz externo:
-
conectores BNC para seales informacin.

interaccin usuario mquina pantalla, botones.
PGINA 20
transferencia energa elctrica a travs de la toma de corriente.

transferencia de calor ventilador trasero.
ACOPLOS
interacciones no deseadas. Hasta ahora hemos hablado de interacciones

deseadas. Una interaccin no deseada es, por ejemplo, la diafona en los sistemas de
telefona.
El interfaz es un filtro selectivo. Transfiere lo que queramos y no deja pasar lo

que no queramos. En realidad, lo que hace es atenuar las interacciones no deseadas, no
las puede eliminar completamente. Hay que evitar la transferencia de fallos, no
atenuarlas.
La capacidad de diseo de un interfaz.
El interfaz puede ser:
-
entre dos elementos fijos es el caso ms sencillo. Si nos equivocamos no es

demasiado grave el Sistema puede an funcionar. Adems, es fcil volver atrs.
- entre dos elementos intercambiables tenemos elementos distintos que se quiere
comunicar. Un ejemplo es el interfaz RS-232 (cable de impresora). Es un interfaz ms
complejo:
interacciones ms variadas.
difcil volver atrs si nos equivocamos, porque no podemos cambiar los
elementos. De hecho, no los conocemos.
- entre varios elementos intercambiables es muy complicado. Siempre tratamos de
evitarlos, cuando sea posible. Algunos ejemplos: autobs, interfaz aire de
comunicaciones mviles.
EJEMPLO: RS-232.
Su origen era para la comunicacin de ordenadores a travs de la red telefnica

pblica.
El interfaz RS-232 tiene las siguientes partes:
PGINA 21
funcional
elctrica dinmica
elctrica esttica
mecnica fsica
fotocopia 33.5
Caractersticas de los interfaces (propiedades).
Veamos cada una:
-
funcionalidad hay que definir lo que har el interfaz en caso de producirse una
situacin anmala. Esto, tambin, forma parte de la funcionalidad.
prestaciones mide la efectividad del interfaz en la transferencia.
tolerancia de parmetros en un Sistema continuo no existe la precisin absoluta
(ejemplo: valores de tensiones en lnea elctrica) hay que dar tolerancias al
transmisor y al receptor. Cuanto ms pequeas sean las tolerancias, ms difcil es
disear los extremos.
El interfaz RS-232 es muy tolerante. Un problema de tener tolerancia grande
es la verificacin hay ms combinaciones posibles. Adems, en general, un interfaz
ms tolerante es menos eficiente.
REGLA no seas intolerante si no es necesario.
filtrado / aislamiento un interfaz deja pasar las transferencias deseadas, se
comporta como un filtro: atenuar o aislar las transferencias no deseadas. Se consigue
a costa de reducir mucho las prestaciones. Por ejemplo, RS-232 hilos paralelos
diafonas. Cmo se evita? Disminuyendo la velocidad del terminal. Habr un
compromiso entre atenuacin prestaciones.
proteccin la interaccin indeseada puede producir daos en el otro extremo, es
parecido a lo anterior. Se busca que el interfaz produzca una aislamiento que, aunque
funcione mal, no dae la transferencia deseada. Por ejemplo, interfaces hombre
mquina, destruye mquina por interaccin indeseada.
Dos casos especialmente importante:
interfaces externos casi siempre hay que preverlo, pues no lo
controlamos (el otro extremo).
interfaces interiores en principio no hara falta, pero hay un caso:
usando datos redundantes si falla un elemento, que funcione el otro pero
sin que le afecte el fallo (los elementos redundantes suelen estar unidos).
extensibilidad un interfaz es extensible si permite aumentar su funcionalidad o
prestaciones (capacidad de transmisin) ms all de lo inicialmente permitido. Con
un coste muy pequeo. El interfaz es capaz de tener mayor prestaciones y
funcionabilidad. Por ejemplo, direccionamiento (mala extensibilidad si es cara).
Veamos el ejemplo; problemas de direccionamiento: 24 procesadores, bus de 5
hilos (extensible a 32 procesadores). Con el coste mnimo de poner un hilo ms,
podramos ampliar hasta 64 con coste muy pequeo, a lo mejor no hace falta pero al
ser el coste tan pequeo. Los interfaces se disean al principio y son difciles
cambiarlos despus, en telecomunicacin. Tampoco es fcil preverlo, debido a que la
tecnologa crece exponencialmente (ejemplo, PC).
PGINA 22
Tema 3: Caractersticas de los Sistemas.

-
Proceso de explotacin.
Caractersticas especiales. (relacionados con cosas paralelas al servicio)
fiabilidad.
mantenibilidad.
Fiabilidad.
Mantenibilidad.
Procesos de explotacin.
Durante la fase de explotacin se hace:
-
fabricacin construccin de mltiples realizaciones del Sistema.

instalacin particularizacin de una realizacin a las necesidades concretas de un
usuario. A partir de aqu (no inclusive) empieza el servicio.
- operacin el Sistema necesitar rdenes concretas por parte del hombre.
- mantenimiento los sistemas fsicos se degradan; intentamos mantener el servicio
como al principio.
- soporte una actividad que destaca es la distribucin. El soporte da servicio a la
operacin y mantenimiento.
Vemos qu pasa cuando el Sistema est en explotacin (vista funcional):
El subsistema funcional es una realizacin del Sistema. Veamos cmo se

comunican las distintas funciones que se realizan durante la explotacin:
(1).- Accin, mantenimiento, instalacin. Prev los fallos. Es una funcin correctiva
(responde a informacin de fallos) o preventiva. Tambin hace actualizaciones para
ampliacin de servicios o errores del sistema detectados durante el ciclo de vida.
(2).- Informacin de fallos.
(3).(4).(5).(6).(7).(8).(9).(10).(11).(12).(13).(14).-
PGINA 23
Informacin de operacin: estado, alarmas.

Orden de operacin.
Informacin de problemas de mantenimiento.
Equipos, repuestos, transporte. Talleres.
Documentacin, formacin y gestin.
Documentacin, formacin y gestin.
Informacin de problemas de operacin.
Equipos, repuestos y reparaciones.
Actualizacin de configuracin si hay que cambiar los sistemas instalados.
Informacin de problemas (peticin de cambio).
Actualizacin de configuracin.
Informacin de problemas (peticin de cambio) de fabricacin.
La ingeniera de Sistemas redisea el Sistema a partir de nuevas necesidades del

cliente. Esta funcin gestiona, configura y hace el mantenimiento del Sistema.
fallo estado de un sistema cuando no es capaz de ofrecer totalmente el servicio.
La funcin de soporte controla (gestiona) todo. Hace la funcin de distribucin
(logstica), distribuyendo: las entradas, los equipos, las respuestas y la documentacin.
Tambin canaliza los informes de los problemas (que al mantenimiento y a la operacin
no les parece normales) como peticiones de cambio. Vemos un resumen de esto en la
fotocopia 52.11.
La configuracin es el conjunto de documentos del Sistema.
Un problema tpico de telecomunicacin es que estas funciones tiene
caractersticas de rea extensa; es decir, todas esas funciones estn distribuidas en reas
muy extensas y se complica el problema. Por ejemplo, la red de telefona. Es la red de
acceso de telefona mvil (mantenimiento, operacin y soporte), cajeros de banca, red
de telecontrol. Se suelen montar con redes jerrquicas, as algunas funciones se hacen a
distancia (las ms complejas) y las ms sencillas cerca (sustitucin de un elemento).
Nos dicen lo bueno que es el servicio. Son las que vienen en las hojas de
caractersticas:
-
funcionalidad descripcin detallada del servicio que ofrece el Sistema, sin

cuantificarla.
- prestaciones cuantifica el servicio (pueden estar relacionadas con varios
interfaces).
- interfaces exteriores interacciones del Sistema con sistemas exteriores.
En el diseo hay que plantearse la funcionalidad y las prestaciones en
condiciones normales (nominales). Se considera tres posibles estados de las
condiciones:
M.Op. Manuales de Operacin.
PGINA 24
condiciones normales habitualmente soportar el sistema (lo tpico).

condiciones anormales permitidas pequea probabilidad de que el sistema se
encuentre aqu. Puede ser:
funcionamiento anmalo de sistema exterior.
valores de parmetros fuera de los nominales (debido a condiciones
exteriores)
solicitud de prestaciones fuera de lo nominal.
Estas dos ltimas se deben a la sobrecarga.
- condiciones no permitidas.
Un sistema est sobrecargado cuando est fuera de las condiciones normales,
pero dentro de las tolerancias. A la sobrecarga tambin se le llama esfuerzo.
Qu hace el Sistema en condiciones anormales?
-
debe permitir, tolerar esos comportamientos exteriores anmalos sin que influya
negativamente al funcionamiento del sistema.
- debe incluir proteccin; a veces, incluye la interrupcin del servicio.
- incluye funciones de control de sobrecarga, evitando llegar a la sobrecarga mxima
para que degradando el servicio de manera razonable y no llegar a interrumpirlo.
Para el diseo hay que tener en cuenta todo esto, para las hojas de las
caractersticas slo hay que tener en cuenta lo nominal.
Respecto al interfaz externo, un sistema es conforme a tal interfaz. La
conformidad quiere decir que el sistema cumple las especificaciones de ese interfaz. La
interoperatividad es algo ms general; no se refiere a un interfaz, se refiere al sistema: el
sistema interopera con tal otro sistema.
(estas cosas aparecen en hoja de especificaciones de requisitos).
Caractersticas especiales.
-
usabilidad.
configurabilidad.
escalabilidad.
fabricabilidad.
evolucionabilidad.
fiabilidad
mantenibilidad.
disponibilidad.
usabilidad caracterstica relacionada con el interfaz del operador del sistema,
interaccin del sistema y los humanos. Los interfaces de operacin se basan en los
sentidos humanos, tanto en entrada como en salida. Buscamos:
facilidad y eficacia con la Operacin
facilidad y eficacia con el aprendizaje a veces, el aprendizaje est
restringido por lo que ya se sabe hacer. Ejemplo: QWERTY.
PGINA 25
Esta facilidad y eficacia de Operacin y de aprendizaje dependen de

cmo sea el interfaz de Operacin y de la documentacin.
ergonoma estudio de aspectos biolgicos y tecnolgicos de la adaptacin
mutua entre personas y mquinas. Depende del diseo del interfaz de
operacin.
Algunos interfaces de operacin:
automvil difcil cambiar el interfaz.
telfono muchos aos igual, hasta la llegada del mvil.
ordenador personal mayor usabilidad gracias al interfaz grfico.
grabador programable de video difcil interfaz de operacin.
- configurabilidad y escalabilidad es la posibilidad de que el Sistema sea
configurable y escalable, es decir, construir distintas realizaciones del Sistema que
tengan, o bien, un subconjunto de la funcionalidad completa o bien prestaciones
reducidas; a cambio de un coste (de la realizacin y de la explotacin), tamao.
La escalabilidad se refiere a las prestaciones. Las estructuras modulares tienen
una buena escalabilidad y configurabilidad.
- fabricabilidad es la facilidad de fabricacin. La fabricacin es la construccin de
mltiples realizaciones del Sistema. Las estructuras modulares ayudan en la
fabricabilidad. Veamos el proceso de fabricacin cuando usamos una estructura
modular:
Las pruebas suelen ser ms o menos restrictivas, se suelen intercalar pruebas

para evitar la propagacin de errores: difcil determinar y / o sustituir. A veces estos
tambin estn separados fsicamente.
Los mdulos suelen tener funcionalidades concretas. Las entradas a este
proceso son:
documentos:
pedidos nmero de unidades y configuracin de cada una.
especificacin de partes qu es lo que tiene que hacer cada una
de las partes que se ensamblarn.
estructura del producto (o vista del producto) Sistema descrito
donde lo importante es de qu mdulos se componen, sus partes y
posibles combinaciones de configuracin de equipo.
PGINA 26
especificaciones de ensamblaje de equipo y de mdulo (o de

montaje) qu piezas encajan, se unen, localizacin de
componentes. Las de equipo son ms complicadas, pues puede
haber distintas configuraciones.
especificaciones de prueba lo hace la ingeniera de Sistemas,
quien disea el Sistema tiene que hacer todo esto (menos los
pedidos). Cul ser el alcance de las pruebas?
Veamos de qu depende la fabricabilidad, los factores que le afectan (hay que
tenerlo en cuenta a la hora de disear el Sistema):
uso de la estructura modular el primer proceso es facilitarlo, esto es,
minimizar el nmero total de partes, nmero de suministradores,
tolerancia de las especificaciones de parte.
adecuada documentacin.
facilidad de adquisicin (o comprar).
facilidad de ensamble un factor importante es la complejidad (mnimo
nmero de mdulos distintos y nmero de partes por mdulo). Debe
existir la posibilidad de hacer ensamblaje automtico. Reducir el nmero
de mdulos distintos (inversamente proporcional a la configurabilidad) y
nmero de partes (adquisicin ms fcil). Respecto al nmero de
mdulos, se puede buscar un exceso de funcionabilidad mdulos que a
su vez sean configurables.
facilidad de prueba ayuda tambin la automatizacin de las pruebas.
Se intentar hacer lo mejor que se pueda, dentro de los costes. El reducir el
nmero de mdulos y partes es bueno, tambin, para el punto de vista de diseo y de
la mantenibilidad, a parte de la fabricabilidad.
EJEMPLO: SISTEMA DE TRANSMISIN MODULAR CONFIGURABLE, PENSADO PARA HACER
UNA FABRICACIN FLEXIBLE (PDH).
Veamos una realizacin:
Veamos cul es la estructura funcional:

fotocopia 52.2
PGINA 27
Esto es una solucin para los operadores de comunicacin y / o

empresas, tambin es escalable. Vemos en la fotocopia de arriba la estructura del
Sistema que usa la jerarqua plesiocrana, segn la ITU. Vemos que hay cuatro
interfaces entre dos multiplexadores.
Vemos todas las posibles configuraciones que hay. Tambin hay
mdulos de alimentacin; su nmero depender del nmero total de mdulos
que haya. Hay un conmutador para poder tener el enlace conmutado. La
estructura fsica significa que empaquetamos toda esta funcionalidad.
Todas las funciones que se nos ocurra deben caber en el mismo espacio
fsico (modularidad fsica). Las complejidades iguales en tamaos iguales.
Las unidades antes se montan en armazones (tambin las unidades de
alimentacin). La placa madre se usa para interfaces exteriores como las
exteriores.
La vista (estructura) de producto nos dice qu combinaciones son
posibles.
Tambin salen los armazones, los que caben en cada uno. Cada uno de
los armazones tiene alimentacin doble.
Normalmente, esto es un equipo de transmisin, distinto al resto; pues
cada usuario tiene necesidades distintas problema de fabricacin, ya que los
mdulos son muy caros y por ello se hace a medida, tanto la configuracin como
el mdulo. Requiere una tcnica de fabricacin complicada: pedido mdulo
que se requiere y se fabrica.
Hemos visto, tambin, la escalabilidad y coste proporcionado al nmero de
canales. Hay una configuracin mnima.
-
evolucionabilidad- es la facilidad de extender el ciclo de vida del Sistema

adaptndolo. Los Sistemas mueren porque:
aparecen nuevos requisitos podemos adaptar los Sistemas.
disponibilidad de nueva tecnologa (ms barata).
Se intenta adaptarles a estos cambios. Tambin puede ocurrir la obsolencia:
degradacin de la utilidad.
Los cambios que podemos hacer el Sistema:
extensiones.
mejora.
cambios de tecnologa.
Los factores que hacen que un Sistema sea evolucionable:
PGINA 28
estructuracin estructura de alto nivel del Sistema, funcionalmente

como vistas reales: cambiar solo una parte del Sistema.
interfaces internos (y externos, vindolos) al hacer la estructuracin.
Hacer los interfaces extensibles en funcionabilidad. Los interfaces son
difciles de cambios.
documentacin hay sistemas que duran muchos aos. Para hacer
cambios en un Sistema es conveniente documentar el porqu se hacen las
cosas para permitir su evolucionabilidad
Hay decisiones de alto nivel.
Fiabilidad.
-
concepto.
medida.
modelos (representaciones simplificadas del comportamiento).
fiabilidad y esfuerzo.
fiabilidad y estructura.
fiabilidad y errores.
Concepto.
Es la probabilidad de que un Sistema funcione satisfactoriamente durante un
periodo de tiempo dado y bajo unas determinadas condiciones.
En esta simplificacin suponemos que un Sistema puede estar en dos estados: en
servicio y en fallo (no es capaz de ofrecer servicio). Esto es muy drstico.
El estado en que est el Sistema depende del tiempo. Con el tiempo todos los
sistemas acaban fallando, es una visin pesimista. Lo que no sabemos es cuando falla.
As que el estado en que est el sistema lo representamos a travs de una funcin binaria
dependiente del tiempo, una funcin probabilstica.
Las condiciones influyen en la fiabilidad, puede ser la temperatura o el trabajo
que est haciendo (esfuerzo).
Medidas.
El sistema podr estar en dos estados, lo representamos:
PGINA 29
Se define ciertas funciones:

-
funcin de fiabilidad, R(t) es la probabilidad de no haber fallado pasado un

tiempo t desde que el sistema entr en servicio. Tambin se llama: funcin de
supervivencia. La experiencia nos dice que la funcin de fiabilidad es una funcin
montonamente decreciente.
funcin de distribucin de fallos, F(t) es la probabilidad de haber fallado ya,

pasado un tiempo t. Es la complementaria a la anterior. Es montonamente
creciente.
funcin de densidad de fallo, f(t) tambin es decreciente. Cuanto ms tiempo

pasa, ms probabilidad de fallo.
PGINA 30
MTTF (Tiempo medio hasta el fallo) es una media. Es muy usado, pues es un
nmero, pero no nos da el comportamiento.
MTTF = t f (t )dt
0
Funcin tasa de fallos, z(t) es parecida a la densidad de fallos. Es la probabilidad

condicionada (condicional) a que el sistema no haya fallado ya.
falloen(t , t + dt ) f (t )dt
f (t )
=
z (t )dt= pr
z (t ) =
R(t )
R(t )
nofalloen int ervalo' t '
La tasa de fallo ya no est claro que sea decreciente, de hecho puede ser
creciente. Los sistemas que envejecen son aquellos que su tasa de fallo va creciendo.
Modelos.
Un modelo es suponer un comportamiento. Para representar la finalidad se usan

expresiones matemticas:
-
exponencial.
Weibull.
MODELO EXPONENCIAL.
Slo tenemos un parmetro , suponiendo: R(t ) = e t ; f (t ) = e t ; z (t ) = ;
1
MTTF = .
Este modelo implica que la tasa de fallos es constante, es decir, que el sistema no
envejece. En este caso, El tiempo medio hasta el fallo es el inverso de la tasa de fallos.
Los importante es el concepto, no las frmulas; slo ayudan a entender lo que
significan.
PGINA 31
MODELO DE WEIBULL.
Es tambin una funcin exponencial, pero ms complicada: R(t ) = e t . Para

=1, tenemos (el modelo exponencial) la tasa de fallos constante: z (t ) = t 1 .
> 1 tasa de fallos creciente.

= 1 tasa de fallos constante.
< 1 tasa de fallos decreciente.
Este modelo se usa para representar un comportamiento de tasa de fallos

variante en el tiempo.
Estos dos modelos tienen parmetros. Veamos de qu dependen los parmetros
de los modelos de fiabilidad:
-
tipo de elemento (de tecnologa).

proceso de fabricacin.
condiciones: esfuerzo (cantidad de trabajo que hacen).
dentro de fiabilidad.
EJEMPLO: DISPOSITIVO ELECTRNICO.
No se puede representar con ningn modelo, pero la parte constante suele ser
mucho ms larga que el tiempo de tasa de fallo creciente y decreciente. Solemos usar la
divisin en tres zonas, como vemos en el dibujo.
La primera zona se debe a problemas de proceso. Los que superan el primer
instante (mortalidad infantil de los dispositivos electrnicos) ya tienen la tasa de fallos
constante. Al final tienden a envejecer.
Normalmente, los componentes electrnicos se usan durante el tiempo de tasa de
fallos constante; pasado ese tiempo (que es conocido por la experiencia), se tira. Antes
de usar los componentes electrnicos, se ponen en funcionamiento, para que se mueran
los que tengan fallos de fabricacin: quemar el equipo. Ese quemado sirve para
PGINA 32
asegurar que el sistema se encuentra en la zona de tasa de fallos constante, antes de

drselo al usuario. En esta zona podemos predecir la fiabilidad, pues conocemos la tasa
de fallos del componente.
Los componentes pueden ser ms o menos fiables, dependiendo de si es mayor
o menor. Los dispositivos mecnicos se comportan:
Fiabilidad y esfuerzo.
La fiabilidad depende de las condiciones en la que el sistema funcione. Se define

unas condiciones normales. Si el sistema no est en condiciones normales, se dice que
el sistema est sometido a esfuerzo. El esfuerzo se mide en funcin de magnitudes que
miden esas condiciones normales:
esfuerzo =
valor _ aplicado
valor _ mximo _ permitido
El esfuerzo unidad es el mximo en que un sistema funciona.

Un sistema en condiciones normales tiene mejor fiabilidad que cuando est
sometido a esfuerzo. La fiabilidad2 de los sistemas decrece cuando crece su esfuerzo,
tanto peor cuanto ms nos acercamos a los valores lmites.
El esfuerzo se puede referir a:
-
condiciones externas. Ejemplo: voltaje aplicado.

consecuencias de las condiciones. Ejemplo: potencia disipada. Es consecuencia de
las condiciones externas, pero no es una condicin externa.
Las condiciones del esfuerzo:
esfuerzo intencionado a veces es til someter los sistemas a esfuerzos

intencionalmente. Ejemplo: funcionamiento para la mortalidad infantil para
fiabilidad probabilidad de que el sistema ofrezca el servicio.
PGINA 33
condiciones esforzadas, acotando este tiempo (dentro del margen permitido). Otro
ejemplo sera medir hasta el tiempo medio de fallo del sistema, que a veces es de
aos, por esos se usa en condiciones forzadas. A veces, es til el esfuerzo.
- las condiciones normales deben estar lejos de las condiciones mximas para el
rendimiento mximo siendo ms fiable (menor esfuerzo). Para que el sistema sea
fiable, sobredimensionamos las cosas (ojo, que tambin cuesta dinero).
Un sistema funciona igual en condiciones normales que en sobrecarga, pero la
probabilidad de fallo aumenta conforme aumenta el esfuerzo.
Fiabilidad y estructura.
La estructura de fiabilidad es una representacin del comportamiento del

Sistema desde el punto de vista de la fiabilidad (falla o no falla). Veamos varios casos:
estructura no redundantes.
redundancia simple.
redundancia compleja.
ESTRUCTURA NO REDUNDANTES.
Se dice que en un sistema no hay redundancia si para que el sistema funcione,
todos los elementos deben funcionar (no sobra nada).
El fallo de un elemento cualquiera implica fallo del sistema. Por ejemplo:
sistema telefnico, ordenador. Hay varias formas de representar la fiabilidad del sistema
con la fiabilidad de cada uno de los elementos (siendo stos independientes entre s).
Conocidas las funciones de supervivencia de cada elemento, podemos conocer la

funcin de supervivencia del Sistema global (depende de sus elementos) (N es el
nmero de los elementos):
N
R(t ) = Ri (t )
i=1
Se suele suponer el modelo exponencial, es decir, los elementos tiene la tasa de

fallos constante:
N
i =1
i =1
R(t ) = R(t ) = exp( i t ) = exp( i t ) = e t

i =1
El sistema completo tambin tiene la tasa de fallos constante. Funciona con el

modelo exponencial, donde la tasa de fallos es la suma de las tasas de cada uno de sus
elementos. Tambin es fcil calcular:
N
i =1
i =1
MTTF = 1 = ( i ) 1 MTTF 1 = MTTFi 1
PGINA 34
Vemos que el elemento que tiene menos tiempo medio hasta el fallo es el que
domina. Otra forma de representacin es mediante el smil elctrico:
Es el estudio ms simplificado:
ESTRUCTURAS CON REDUNDANCIAS SIMPLE.

Un sistema tiene redundancia cuando se puede quitar un elemento y el Sistema
sigue haciendo lo mismo, con el mismo comportamiento exterior y la misma funcin.
La redundancia simple consiste en repetir un elemento (misma funcin). Hay
dos tipos de redundancia:
redundancia activo reserva de los elementos repetidos, slo uno cumple con su
funcin y los otros estn inactivos.
redundancia en reparto de carga la carga total del trabajo a hacer se reparte entre
los elementos redundantes, aunque uno de ellos fuera capaz de hacer todo el trabajo.
El orden de redundancia se indica: M:N. El orden de redundancia trata de ser
una cierta medida de la redundancia, donde N es el nmero de elementos necesarios
para realizar la funcin (prestaciones requeridas). As si M es mayor que N s que hay
redundancia; por ejemplo si M = N + m, m ser el nmero de elementos no
necesarios para cumplir con las prestaciones del Sistema:
N:N, 1:1 no hay redundancia.
1+1:1 caso tpico, donde hay uno de reserva. Por ejemplo, alimentacin de
grandes centros de informacin.
1+N:1 tenemos N elementos en reserva. Puede fallar hasta N elementos. Por
ejemplo, los motores de los aviones.
N+m:N es el caso general, pueden fallar hasta m elementos en el sistema.
Veamos el caso tpico N:1. Puede fallar N 1 elementos y el sistema seguira
dando servicio. El Sistema falla slo si todos los elementos fallan, por eso tambin
recibe el nombre de estructura en paralelo. Se pueden representar con una funcin
AND.
R(t ) = 1 (1 Ri (t ))
PGINA 35
Se puede resolver este caso si la tasa de fallos de todos los elementos son
iguales:
1 N 1
i iguales = MTTF =
i =1 i
Mejoramos un poco para el tiempo medio hasta el fallo; es ms, si crece i la
ganancia marginal es cada vez peor.
Con reparto de carga, la fiabilidad de cada uno de los elementos es mejor pues
menor es el esfuerzo de cada elemento, pero no se refleja en la frmula. En activo /
reserva, el elemento que est en reserva tendr una tasa de fallos bastante menor, siendo
esta diferencia mayor o menor dependiendo del esfuerzo del elemento activo. El activo /
reserva se usa para un Sistema con desgaste, as el elemento en reserva no tendr
desgaste (la tasa de fallos no crece).
La realidad es ms complicada. La forma de aumentar la fiabilidad con ms
elementos es si podemos recuperar los elementos. Hemos calculado el tiempo de fallos
de todos los elementos, pero las estructuras redundantes son ms tiles si los elementos
son recuperables mediante una accin de mantenimiento.
Si el Sistema es recuperable, el Sistema cambia mucho. Mientras uno funciona,
recuperamos el elemento que estaba en fallo. Por ejemplo con dos elementos:
PGINA 36
1,5
2 2 TM
sin mantenimiento: MTTF 1 =

con mantenimiento: MTTF 1
Lo normal es que se utilice redundancia simple con mantenimiento, pudiendo

hacer que el tiempo medio hasta el fallo sea muy alto, ya que podemos hacer que el
tiempo medio de recuperacin (TM) sea chico. Pero no siempre se puede hacer
mantenimiento, por ejemplo en el satlite. En telecomunicacin se puede hacer
mantenimiento, mejorando mucho el tiempo medio hasta el fallo.
Hemos supuesto la independencia entre fallos de los elementos, pero no es fcil
conseguirlo en sistemas electrnicos. Normalmente, cuando se hacen Sistemas
redundantes, a los elementos se les llaman bloque de fiabilidad, si son capaces de
aislar, desde el punto de vista de transferencia, el fallo.
Hasta ahora esto era muy drstico: el Sistema falla o funciona. En los sistemas
complejos no se habla de fallos de servicio, sino de degradacin de las prestaciones y si
se viene abajo es que ya no es capaz de hacer nada.
REDUNDANCIA COMPLEJA.
Las formas ms complejas de modelar el fallo:
Grado de servicio.
o Vulnerabilidad.
Modo de fallo.
Se usa el concepto de grado de servicio siempre que la degradacin del
servicio sea aceptable, usando un nmero que expresa lo lejos que estamos del servicio
total. 0 ser el fallo total y 1 servicio completo.
En relacin de esto, se refiere a la vulnerabilidad de un Sistema al fallo de un
elemento. La experiencia nos dice qu sistemas son ms vulnerables que otros y qu
elementos influyen ms en la vulnerabilidad que otros. Tambin pueden ir de 0 a 1,
siendo 0 el elemento invulnerable y 1 la vulnerabilidad total.
Si los elementos no estn bien aislados; si uno de ellos es vulnerable, el resto de
elementos tambin son vulnerables al fallo.
Los elementos, hasta ahora, tambin tenan dos estados. A veces se usan varios
estados para los elementos.
Los modos de fallos consisten en que tanto el sistema como los elementos estn
en varios estados: en servicio o modos de fallos. El fallo significa degradacin de la
funcionalidad. Los modos de fallos no hace falta que sean continuos. El modo de fallo
se define como efecto del servicio, no la causa. Por ejemplo, el modo de fallo del
condensador sera: el valor C se sale de la tolerancia, circuito abierto, cortocircuito.
PGINA 37
A veces se dibujan diagramas para los modos de fallos:
Este tipo de diagrama sirve:

para ver qu modo de fallo se produce cuando se produce un fallo de un dispositivo:
ANLISIS DE MODOS DE FALLOS Y SUS EFECTOS.
permite calcular la fiabilidad.
permite hacer estudios de la vulnerabilidad.
Fiabilidad y los errores3.
Al hablar de fiabilidad asumimos que los sistemas fsicos se degradan sin

remedio. Los Sistemas complejos fallan, muchas veces, y no se debe a una degradacin
fsica de los componentes electrnicos. Los Sistemas fallan por no estar bien hechos,
tienen errores o bien de diseo o bien de fabricacin.
Se puede evitar los errores? S que se puede. Esto se consigue diseando bien y
probando. Se reducen los errores pero no del todo, ya que siempre se cuelan errores.
Pero las pruebas se hacen con recursos limitados de tiempo y en recursos. Entonces, por
pesimismo, todos los Sistemas tienen errores.
-
fallo dejar de cumplir su funcin, su servicio. Se produce en el servicio.

error asociado a un fallo de la actividad de diseo. Est en el Sistema.
Nos referimos a errores de diseo y de fabricacin.
PGINA 38
Un error siempre provoca fallo? No siempre. El fallo del sistema se produce si

se produce ciertas condiciones, como un estado no previsto en el diseo. El error se
manifiesta en el fallo. Si el Sistema no pasa por ese estado, no se manifestar el error. El
fallo depende de las condiciones del sistema. No siempre un error produce fallo.
Al disear un Sistema no sabemos cules son los errores ni las condiciones
necesarias para que si hay errores, se produzcan fallos. No podemos hacer nada
determinista. Haremos de esto un problema estadstico, un problema de fiabilidad.
Los errores lo tratamos como un problema ms de fiabilidad. Con este tipo de
fiabilidad, si un sistema entra en modo fallo es fcilmente recuperable, requiriendo una
accin: el re arranque.
Los Sistemas software tambin fallan, buscaremos algo relacionado con la
fiabilidad, factores que influyen en la fiabilidad relacionada con los fallos debido a los
errores del Sistema. Vemos de qu depende la fiabilidad de un Sistema lgico (no hay
degradacin fsica):
complejidad cuanto ms complejo sea un Sistema, ms difcil de disear ms
errores.
- proceso de desarrollo el proceso de desarrollo consiste en: diseo y prueba.
Influye en el nmero de errores que queden en el Sistema.
- esfuerzo cuando un Sistema hace ms trabajo, el nmero de combinaciones de
estados que se produce es muy alto, mayor probabilidad de caer en un estado no
diseado. Los errores son los mismos, pero la probabilidad de que los errores se
conviertan en fallos es mayor.
MODELOS DE FIABILIDAD DEBIDA A LOS ERRORES.

Hay varios modelos:
Modelo de tasa de fallos constante suponemos que el sistema tiene un
determinado nmero de errores y que la tasa de fallos es constante. Cuando falla el
sistema, lo re arrancaremos, teniendo el mismo nmero de errores y la misma tasa
de fallos constante que antes. Ya vimos los factores que influan en la tasa de fallos.
- Modelo de tasa de fallos, z(t), decreciente tpico comportamiento en fase de
depuracin, diseo, experimentacin y en la explotacin. Ahora cuando se produce
un fallo, investigamos: sus causas, el error que provoca el fallo y las condiciones en
las que se dan. Corregimos el fallo eliminando la probabilidad de que se produzca un
error:
o eliminar el error o
o eliminar las condiciones
En la fase de explotacin, se elimina el fallo de la forma ms fcil posible. Es

lo que se denomina parche; pues no se corrige la estructura, sino evitar las
condiciones de fallo.
- Modelo de introduccin de versiones en los sistemas complejos, cuando entra en
la fase de explotacin, al detectar un error grave, los diseadores del sistema
proponen un parche sin cambios estructurales. Esto reduce la tasa de fallos del
sistema, pero no baja de un determinado nivel.
PGINA 39
Se introduce una nueva versin del sistema al hacer cambios estructurales

cuando hay muchos parches, corrigiendo los errores a ms bajo nivel. Pero las nuevas
versiones tiene una tasa de error mayor a la anterior, pues se trata de una nueva
versin.
Pero la tasa de error se baja un poco, conforme se vayan detectando los

errores. En los nuevas versiones, a parte de la correccin de errores, se le aaden
nuevas funcionalidades, aumentando un poco ms la tasa de fallo.
RESUMEN DE FIABILIDAD.
-
concepto
medida
modelos
esfuerzo
estructura
fiabilidad y errores (de diseo o de fabricacin)
Mantenibilidad.
- concepto.
- tipos de mantenimiento.
- medida.
- disponibilidad.
- mantenimiento automtico.
---- mantenimiento del sistema (es muy distinto a los de arriba, tambin se le llama
mantenimiento adaptativo).
Concepto.
Los sistemas, tarde o temprano, fallan. Sin embargo, la mayora de los sistemas
son recuperables, esto es, podemos volver a dar el servicio, a volver al estado anterior.
Esto se hace mediante una accin de mantenimiento. Si los sistemas son recuperables,
se habla de tiempo medio entre fallos; ms que tiempo medio hasta el fallo, pero es el
mismo concepto.
PGINA 40
Pero existe otro tipo de mantenimiento, que consiste en evitar que el sistema
falle (sobretodo para sistemas con desgastes). Tiene como objetivo aumentar la
fiabilidad.
La Mantenibilidad es una caracterstica del sistema que consiste en la facilidad,
la seguridad, la eficacia, la economa y la precisin con que se puede realizar la
actividad del mantenimiento de un sistema.
Veamos una definicin de mantenibilidad: probabilidad de que un sistema (lo
que se degrada es la realizacin del sistema) sea retenido en (repuesto a) una condicin
(un estado) especificado en un tiempo dado mediante acciones de mantenimiento con
procedimientos y recursos definidos.
El mantenimiento es una accin normalmente lo hace una organizacin
(equipos) con una serie de recursos del sistema. La mantenibilidad s es responsabilidad
de la ingeniera del Sistema, pues la mantenibilidad se logra en el diseo.
Tipos de mantenimiento.
Se habla de dos tipos:

-
correctivo.
preventivo.
MANTENIMIENTO CORRECTIVO.
Su objetivo es reponer al sistema a un cierto grado de servicio, despus de que
ese grado de servicio ha disminuido a partir de un fallo. A esta accin tambin se llama:
recuperar el sistema. La secuencia que sigue:
fallo accin de mantenimiento correctivo sistema recuperado
Esta accin de mantenimiento correctivo se hace de manera secuencial:
PGINA 41
El ciclo de mantenimiento correctivo tambin se llama tiempo en que el sistema

est fuera de servicio o cado.
La deteccin es darse cuenta de que ha ocurrido el fallo. No siempre es fcil,
depende de la complejidad del sistema. Cuanto ms complejo, ms difcil ser la
deteccin.
La preparacin no depende del sistema (depende de los recursos que tenga la
organizacin), sino de la organizacin del mantenimiento.
El ciclo de mantenimiento activo es lo que ya depende ms del Sistema. As, con
la localizacin averiguamos qu elemento falla y qu hay que hacer para reponer el
sistema.
Para recuperar un elemento hay que desmontar para poder acceder al elemento
que necesito recuperar, lo recupero: reparndolo, cambindolo por otro elemento,...
Despus se monta. Por ltimo hay que verificar que el elemento se ha recuperado y que
hemos ensamblado bien el sistema.
Durante el bloque de desensamble, recuperacin, ensamble y verificacin el
sistema est fuera de servicio, as que es importante que se tarde lo mnimo posible.
Para reducir los tiempos de recuperacin se puede hacer:
sistema con ayudas al diagnstico tiempo de diagnstico corto.
sistema de fcil montaje y desmontaje mucha accesibilidad (pocos elementos o
fcilmente desmontable).
- sistema con verificacin automtica tiempo de verificacin corto.
- una buena documentacin (forma parte del sistema) reduce tambin los tiempos de
recuperacin.
MANTENIMIENTO PREVENTIVO.
Tiene como objetivo retener al sistema en un cierto grado de servicio. El origen
de una accin de mantenimiento preventivo no es un fallo. Hay dos eventos que
desencadenan una accin de mantenimiento preventivo (origen):
supervisin vemos que hay algo que podra producir un fallo, generalmente por
degradacin del sistema.
- programacin peridica sabemos que hay muchos componentes que se desgastan,
producen fallos y conocemos este tiempo. Se pueden sustituir o ajustar, por ejemplo,
en circuitos electrnicos para tener mrgenes de seguridad de mantenimiento. Otro
ejemplo sera el aceite del coche.
-
Se usa con sistemas con tasas de fallos crecientes: sistema con desgaste o
sistemas con tiempo de vida limitado.
Cuando la tasa de fallos es constante no tiene sentido el mantenimiento
preventivo, pero a veces se hace. Ejemplos: reajustes con potencimetros, calibraciones
peridicas.
PGINA 42
Medida.
medida de frecuencia frecuencia a la que se requiere las acciones de

mantenimiento. Se usa el tiempo medio entre mantenimiento (MTBM). En sistemas
de tasa de fallos de constante, el tiempo medio entre mantenimiento es igual al tiempo
medio hasta el fallo del conjunto de los elementos. En el sistema con mantenimiento
preventivo, el tiempo medio entre mantenimiento estar relacionado con el tiempo de
vida til del elemento con desgaste.
- medida de tiempo tiempo que dura la accin de mantenimiento. La medida es el
tiempo de recuperacin (TTR, Time To Restore). En caso de mantenimiento
correctivo, el tiempo de recuperacin incluye todo el ciclo y hay cosas que no
depende del diseo. Tambin llamado tiempo de cada del sistema. El tiempo de
recuperacin depende de lo que hayamos trabajado en el diseo y en la organizacin
de mantenimiento. Muchas veces se usa el tiempo medio de mantenimiento activo,
que es el valor medio que dura el ciclo de mantenimiento activo. La medida de verdad
es el tiempo medio de recuperacin (MTTR), ya que no es determinista.
- medida de coste esfuerzo que requiere en recursos la accin de mantenimiento.
En precio, en cantidad de esfuerzo. El coste no afecta al servicio, la frecuencia y el
tiempo s que repercute al servicio. El coste afecta al que haga el mantenimiento.
Disponibilidad.
Es otro concepto diferente a mantenibilidad. Se habla de disponibilidad en

sistemas recuperables, es decir, en que una vez que falla el sistema se puede poner en el
estado anterior al fallo. La disponibilidad es la probabilidad de que el sistema est en
SERVICIO.
La disponibilidad (A) es la relacin que existe entre el tiempo que est en

servicio y el total:
A=
PGINA 43
MTBF
1
MTBF + MTTR
Valores tpico de la disponibilidad es del 99%, 999%, 99999%; hay una alta
disponibilidad de cincos nueves de disponibilidad. La disponibilidad nos dice el tiempo
til en que el sistema est ofreciendo el servicio.
Para un sistema aparece la fiabilidad (MTBF), la mantenibilidad (MTTR) y la
disponibilidad (A), aunque las tres estn relacionadas. Desde el punto de vista del
servicio, las tres cosas son importante. No interesa una alta disponibilidad y un elevado
tiempo medio entre fallos si tambin tenemos un alto tiempo medio de reparacin,
habra que limitarlo. Tampoco interesa tener bajo tiempo medio entre fallos, por muy
bajo que sea el tiempo medio de reparacin.
1
MTTR = MTBF ( 1)
A
Podemos dibujar la siguiente grfica.
A un sistema le pedimos una disponibilidad mnima, un tiempo medio entre fallo

mnimo y un tiempo medio de recuperacin mximo.
Mantenimiento automtico.
Para un sistema con alta disponibilidad, la deteccin y preparacin no se puede

admitir.
Muchos sistemas complejos tienen funciones automticas, es decir, no requieren
de interaccin humana. Las funciones se automatizan para conseguir:
velocidad de respuesta.
seguridad.
PGINA 44
coste.
En el mantenimiento, se automatizan debido a sus requisitos (por ejemplo, la
velocidad de respuesta) de:
fiabilidad se necesita que el recambio sea rpido (o el rearranque del sistema, si es
software), para aumentar la fiabilidad.
mantenibilidad reduce esos tiempos de recuperacin cuando el sistema est cado.
disponibilidad es una mezcla de las dos anteriores.
Las funciones que hay que automatizar es en el mantenimiento correctivo:
deteccin sistema que se entera si hay un elemento fuera de servicio.
diagnstico saber cul es ese elemento.
Y para el mantenimiento activo:
recuperacin no en el ensamble; sino, por ejemplo, en rearranque o recambio (de
funciones).
fotocopia 51.1.
fotocopia 51.1 abajo.
La supervisin siempre hace falta, ya que es una funcin de detectar los
fallos. La supervisin es a distintos niveles: ms fsicos o de ms alto nivel. El
objetivo de este sistema es detectar los fallos.
El diagnstico decide si se puede recuperar el estado sin necesidad de
intervencin del operario informa a la recuperacin o a la operacin. Este
esquema suele ser de sistemas de telecomunicacin.
MANTENIMIENTO ADAPTATIVO.
Relacionado con la evolucionabilidad del Sistema. Ahora este mantenimiento
se refiere al Sistema. Recibe varios nombres: mantenimiento adaptativo o evolutivo o
del Sistema.
El funcionamiento del Sistema intenta adaptarse a las condiciones cambiantes:
nuevos requisitos (de servicio).
aparicin de nueva tecnologa podemos mejorar la fiabilidad (el Sistema) o
reducir los costes,...
necesidad de corregir los errores que aparecen en el mantenimiento del Sistema se
suele incluir los errores que se hallan durante la fase de explotacin.
PGINA 45
Tema 4: Metodologa del proceso de desarrollo.

Procesos de ingeniera:
o definicin.
o anlisis.
o diseo.
o construccin / ejecucin.
o verificacin.
Procesos de control del Diseo.
Introduccin.
Veremos los mtodos de diseo. El proceso de desarrollo es un proceso humano

que permite, desde una necesidad, obtener un Sistema que resuelve esta necesidad.
Los procesos de ingeniera de modelos simples son independientes: los procesos
de ingeniera se realizan de manera secuencial, y de forma paralela se realizan los
procesos de control del Diseo. Para los modelos ms complejos, se solapan.
El anlisis de los procesos de ingeniera busca la mejor solucin que cumpla esa
especificacin de requisito, segn el criterio de decisin.
Definicin.
PROPSITO definir los objetivos del proyecto.

RESULTADO especificacin de requisitos.
Suele haber dos roles: el cliente y el ingeniero del Sistema. El cliente es capaz de
definir la necesidad. El ingeniero es capaz de disear el Sistema que cumpla la
necesidad.
ALCANCE Hasta dnde llega esta definicin? Vemos:
definir el SERVICIO (no el SISTEMA) no hay que indicar posibles
soluciones del Sistema. Hay que abstraerse a la necesidad. Por ejemplo:
El proyecto: instalar una nueva central telefnica en un barrio. La
necesidad: el servicio telefnico a un nmero de usuario.
El proyecto: instalar un radioenlace. La necesidad: ofrecer un
Sistema para transmitir datos.
El proyecto: construccin de un puente. La necesidad: dar
servicio de trfico entre las orillas.
definicin no ambigua si los requisitos son cuantificables, hay que poner
el nmero. No escribir mucho sin decir nada. Por ejemplo:
reducir el impacto ambiental ?
bajo coste cunto?
agradable a la vista ?
PGINA 46
definicin completa no debe dejarse aspectos importantes sin definir.

Suponer cosas y el sentido comn no es admisible, no se puede suponer que
las cosas son evidentes. Lo que queremos, hay que definirlo. Dar una
definicin formal y completa. Por ejemplo, si queremos una ampliacin de
una red de telecomunicacin: el objetivo es disminuir a la mitad de tiempo de
conexin (alta) de un nuevo usuario que lo solicite en la ciudad de Mlaga de
aqu a un ao, con inversiones menor que X euros.
definicin realizable tiene que haber una solucin, al menos. Si damos una
definicin sin solucin, los ingenieros de anlisis tardarn mucho tiempo en
darse cuenta de que no existe una solucin. Pero lo ms probable es que en la
fase de anlisis, se deseche los requisitos menos importantes hasta que haya
solucin. Esto se sale del modelo y no debe ocurrir. Cmo se sabe si existe
solucin? Por experiencia o por estudios de viabilidad, para evitar este
problema pero que no aparecen en la especificacin de los requisitos. Otros
modelos son los iterativos: los procesos de definicin de anlisis y diseo no
son independientes y s son iterativos, para ir afinando una definicin viable.
Para que una definicin sea realizable, hay que evitar pedirlo todo (parar
de pedir cosas). La dificultad est en poner slo los requisitos que son
necesarios.
ESTRUCTURA DE LA ESPECIFICACIN DE REQUISITO (BLANCHARD) se ponen en orden
para que no se olvide nada. Su estructura:
requisito de usuario (cooperacional) relacionada con el uso (SERVICIO) del
Sistema. Se debe incluir la definicin cualitativa y cuantitativa del SERVICIO.
requisito de soporte relacionados con el mantenimiento, soporte y fabricacin
del Sistema.
requisito de verificacin hasta dnde llega en la verificacin del diseo.
restricciones costes, plazo del proyecto, ...
fotocopia 51.1 vuelta.
Veamos algunos ejemplos de especificacin de requisitos:
EJEMPLO 1: COMPAA GRANDE (REAL).
El cliente es interno, el Marketing. Divide la parte de definicin en dos fases:
fase 1especificacin comercial, la hace el departamento de marketing.
o descripcin de necesidad de forma ambigua, no tcnica.
o posibles usos.
o restricciones de coste del Sistema y del proyecto y del plazo de
desarrollo.
fase 2 especificacin de diseo, es ms tcnica.
Slo aparecen requisitos, no soluciones.
fotocopia 51.2 arriba.
PGINA 47
EJEMPLO 2: EQUIPO DE TRANSMISIN.

Aparecen casi todas las cosas vistas.
EJEMPLO 3: NORMA DE ESPECIFICACIN DE UNA ORGANIZACIN.
Vemos que estn todos los requisitos, pero organizados de distinta forma.
fotocopia 51.2 vuelta leer.
Anlisis.
introduccin.
diseo conceptual.
estructuracin.
especificacin del Sistema conjunto de documentos que resulta de toda esta
accin.
Introduccin.
PROPSITO encontrar el mejor Sistema que cumpla los requisitos.

ENTRADA especificacin de requisitos.
SALIDA especificacin de Sistema.
El objetivo es encontrar un Sistema que cumpla los requisitos, sin plantearse si
esos requisitos cumplen la necesidad inicial o si est bien planteada.
En la definicin se dice lo que tiene que hacer el Sistema y en el anlisis se dice
cmo se tiene que hacer.
Siempre hay un proceso de optimizacin, ya que habr varias posibles
soluciones. En esta fase de anlisis hay que pensar en todo el conjunto completo de
requisitos (en esto se diferencia esta fase de la siguiente).
El resultado es la especificacin de Sistema, que es todo lo que tiene que ir en
este documento (contenido de toda la informacin para poder seguir los procesos):
cmo es el SISTEMA
(descripcin de alto nivel)
cmo se va a desarrollar
cmo se va a probar
cmo se va a explotar
lo que tiene que estar definido

Estructura
Interfaces
Funciones
Tecnologa
Usar y Mantener
PGINA 48
Habr decisiones claves que afecten al resto del proyecto: tecnologa, estructura,
... Lo nico que no hay es detalles de fabricacin.
Veamos cmo se hace el Anlisis. El Anlisis se suele hacer en dos fases
secuenciales:
En la primera fase, se busca una solucin global al Sistema y se toma decisiones

de la principal tecnologa a utilizar (ser determinante). No nos preocupa demasiado
dividir el Sistema en trozos, al menos no por el problema de complejidad sino por una
mejor comprensin. Se toman grandes decisiones, pues afectan al desarrollo.
En la siguiente fase, la estructuracin, s nos preocupa el hecho de que la
solucin elegida hay que disearla y mantenerla. Ahora si nos preocupa la complejidad:
se divide en distintos niveles para que el Sistema sea abordable. Se puede hacer una
estructuracin: funcional, fsica, ... Tambin se considera las estructuras redundantes.
Una vez obtenidas las distintas partes, hay que asignarlas los requisitos del
Sistema entre cada una de las nuevas partes.
En la estructuracin tambin hay que ver cmo desarrollar, probar y explotar.
Aqu nos preocupa la complejidad y en el diseo conceptual nos preocupa menos.
Diseo conceptual.
Ejemplos. Qu se decide?
Procedimiento de anlisis procedimiento de toma de decisin.
Ejemplo.
PGINA 49
Qu se decide?
EJEMPLO 1: decidir entre desarrollar o comprar (generalmente se refiere a partes del

Sistema o al Sistema completo).
Los requisitos que nos piden se pueden cumplir con un Sistema ya existente o
modificndolo un poco o desarrollando un Sistema nuevo.
Partir de un Sistema tiene un coste de desarrollo menor. Tambin est el riesgo
de conseguir los objetivos.
EJEMPLO 2: tecnologa bsica: familia de microprocesadores o sistemas operativos.
Este tipo de decisiones no slo se basan en prestaciones y coste (que tambin
son criterio), tambin influye en el criterio.
herramientas de desarrollo que permiten desarrollar la tecnologa influye en el
tiempo y calidad de desarrollo, esto es en:
o productividad.
o calidad
perspectiva de continuidad y evolucin de esa tecnologa.
EJEMPLO 3: Red de telecontrol.
cableado o no cableado (radio margen de frecuencia).
Procedimiento de anlisis4.
Es el procedimiento de toma de decisiones. Una decisin desafortunada puede

degenerar en graves problemas en el desarrollo. Para las decisiones importantes habr
que seguir este procedimiento de anlisis (de toma de decisin o anlisis de soluciones
candidatas).
El esfuerzo que se le dedique a este procedimiento depender de la importancia
de la decisin que hay que tomar.
fotocopia 51.3 izquierda.
En el criterio de evaluacin, los parmetros de eficacia pueden ser
cuantitativos o un conjuntos de parmetros tiles.
La eficacia es difcil de cuantificar o la funcionalidad. Vemos lo que puede
significar el coste y la eficacia en la fotocopia 51.3 derecha. La ventaja de los costes
es que se pueden cuantificar, la eficacia es ms difcil de cuantificar.
Lo ms fcil es minimizar el coste, pero qu coste: el desarrollo? la
implementacin? Estimar la eficacia es ms difcil.
criterio1: coste evaluar los costes.
4
nos referimos a anlisis porque se trata de la toma de una decisin.
PGINA 50
eficacia
obliga a cuantificar parmetros. Hay que ponderar
cos te
los parmetros de la eficacia.
criterio 2:
Para las alternativas hay que saber bien lo que se nos pide. No hay que
juzgarlas (la decisin viene despus), slo identificarlas.
En el enfoque y tcnicas de evaluacin, a veces la decisin no la podemos
hacer simplemente pensando, hace falta un modelo (representacin) o un prototipo
(realizaciones). Aqu slo se definen.
Existe riesgo cuando algn dato que se necesita para obtener la decisin, no
conocemos su valor pero s su probabilidad. Podemos calcular el riesgo, la
probabilidad de que nuestra decisin no sea adecuada. Incertidumbre es cuando no
se conoce nada.
En la evaluacin de alternativas:
anlisis de sensibilidad si un dato de entrada (no conocido con certeza) vara,
cmo varia el modelo: cunto riesgo?
estudios de compromisos entre parmetros ver cmo se consigue unas
caractersticas deseables a costa de otras.
El anlisis de los resultados nos sirve para ordenar las alternativas.
Lo ltimo es tomar la decisin. En la documentacin hay que poner todas las
decisiones y resultados de lo que se ha hecho. Es muy importante todo lo que no
est en el documento se pierde.
Esto no se hace siempre, slo en las decisiones grandes de un proyecto se hace
todo esto. Para decisiones pequeas se saltarn algunos pasos.
Ejemplo.
Es un ejemplo real de un proyecto grande. Veremos algunas decisiones dentro

del diseo conceptual.
Se trata de una conmutador de paquetes (router) muy grande y con unas
requisitos de disponibilidad muy grande. Veremos algunos requisitos, decisiones y
modelos.
REQUISITOS:
capacidad nmero de mensajes, bits por segundo, enlaces, ...

interfaces lgicos (IP, X.25, ...) y fsicos (RDSI, mdem, ...).
fiabilidad.
disponibilidad.
mantenimiento correctivo de una unidad sin que el Sistema est fuera de servicio.
configurabilidad.
PGINA 51
escalabilidad.
evolucin.
gestin del Sistema.
DECISIONES:
funciones de gestin mquina hardware / software existentes tipo UNIX. (se
compra)
operacin estacin de trabajo con entorno grfico de ventanas. (se compra)
conmutacin (se desarrolla) hardware de proceso y de comunicaciones. El
software nuevo se desarrolla, tanto el de bajo nivel como el de alto nivel.
prctica de equipo todo el soporte de la electrnica.
El Sistema est dividido en: terminal de gestin, centrales de gestin y centrales
de red (conmutacin).
ESTRUCTURA.
fotocopia 51.4 arriba.
La capacidad est limitada por la capacidad del bus UPR. Cada bus tiene
colgadas cierto nmero de unidades funcionales y si ste falla, fallan todas afecta
a la fiabilidad. Si falla un enlace, slo caen las unidades conectadas a l, pero el
resto siguen funcionando.
Para la alimentacin se pens en alimentacin distribuida (a cada elemento) en
vez de central. As mejoraba la fiabilidad.
Tambin se pens en permitir rearrancar cada parte por separado en vez de
todo a la vez, tambin para aumentar la fiabilidad.
Respecto a las Decisiones, decir que lo importante para tomar una decisin es
tener toda la informacin posible y de forma compacta, es decir, haciendo un resumen
para poder mirarla rpidamente y poder compararla de forma fcil.
Estructuracin.
Nos preocupamos de cmo acometer la complejidad del diseo (usaremos el

concepto de Sistema). Tambin nos ocuparemos de cumplir los requisitos que antes no
hemos tenido en cuenta (mantenibilidad, fiabilidad, ...)
Dividiremos el Sistema en otros ms pequeos. Para organizar el trabajo lo
mejor es hacer una divisin funcional, pero haremos tambin otras divisiones.
Divisin funcional.
o caractersticas.
o procedimiento.
o otros criterios de divisin.
PGINA 52
Ejemplos de estructuracin.
Divisin funcional.
CARACTERSTICAS.
a) Funciones fcilmente descritas a pesar de que sean complejas de implementar,
deben ser simples en la definicin. Ejemplo, puerta AND sumador binario.
b) Pocos elementos debemos poder ver la funcin de cada elemento y la global en el
conjunto. Para esto se requieren pocos elementos (entre cuatro y ocho elementos).
c) Interfaces simples debemos tener relaciones simples entre elementos y sistemas.
Dividiremos elementos que no tengan funciones comunes.
d) Pocos interfaces no deben estar todos los elementos relacionados con todos.
Como resumen podramos decir que buscamos la divisin ms sencilla. Si el
Sistema es complejo, debemos hacer una divisin a varios niveles.
PROCEDIMIENTO.
Podra ser una secuencia de cosas:
a) enumerar las funciones.
b) enumerar los sistemas externos con los que interacciona (se les llaman actores).
c) identificar funciones bsicas que no estn en los requisitos, pero que normalmente
permiten implementar las funciones del apartado (a). Ejemplos: reconversin de una
alimentacin en otra.
d) identificar funciones convencionales, que son las que suelen existir ya hechas, para
ver si conviene comprarlas o disearlas.
e) ordenar las funciones por prioridad, importancia, etc.
f) agrupar las funciones, pues son muchas y queremos pocos elementos. Las
agrupamos por el parecido o porque estn fuertemente acopladas. Agrupamos hasta
conseguir cuatro y ocho elementos.
g) dibujar una estructura, para relacionar elementos entre s. Slo deben estar
conectados algunos elementos, no todos con todos.
h) aadir interacciones externas.
i) re estructuracin consiste en pasar funciones de un elemento a otro para
simplificar. As podemos evitar duplicacin o podemos hacer reutilizaciones. A veces
se juntan funciones en un elemento para evitar interacciones externas y tener un
Sistema ms sencillo.
PGINA 53
Si bajamos de nivel podremos describir agrupaciones ms sencillas.

Esta es la divisin funcional. Pero esto debe ser compatible con otras divisiones
del Sistema (real, fsica,...). Por eso suele ser un proceso iterativo.
OTROS CRITERIOS DE DIVISIN (NO FUNCIONALES).
separacin fsica.
flujo en interfaces puede haber limitacin de flujo de informacin debido a la
tecnologa: necesitaremos varios interfaces en vez de uno solo.
prestaciones podemos tener tambin limitaciones tecnolgicas y podemos
necesitar varios interfaces.
verificacin es posible que necesitemos verificar un elemento desde fuera y
necesitemos otro interfaz.
fiabilidad queremos dividir en bloques que tengan ciertas caractersticas.
mantenimiento (fsico) (no del Sistema).
mantenimiento del Sistema puede interesar separar un elemento que evolucione
rpidamente, para sustituirlo.
escalabilidad es mejor muchas partes pequeas que una grande.
EJEMPLOS DE ESTRUCTURACIN.
Debemos fijarnos en el esfuerzo de que est todo y de definiciones de funciones
de una sola palabra, para un mejor entendimiento.
EJEMPLO 1: EQUIPO DE TRANSMISIN DE DATOS POR RED TELEFNICA (ETD).
La primera divisin funcional: modulacin / demodulacin (tratamiento de
seal).
PGINA 54
Vemos que no todo est conectado con todo. Es un equipo sencillo se ahorra
muchos pasos que conocemos.
Si bajamos de nivel, dividimos ms para poder disear por separado.
A cada una de las partes habra que asignar requisitos.
EJEMPLO 2: CONMUTADOR DE PAQUETES.
Es el ejemplo que vimos antes, pero entrando en detalle. As la divisin
funcional queda:
la funcin principal es la conmutacin.
otra gran funcin es la gestin--> puede realizarlo otra mquina, pero lo vemos aqu.
Veremos los nodos de conmutacin, pero requieren cierta gestin.
fotocopia 51.5.
No repetiremos trabajo si hemos sido capaces de identificarlo bien. Dentro de
la divisin funcional (las cinco grandes funciones vistas en la fotocopia) est la
prctica de equipos que tiene las siguientes funciones:
soporte mecnico.
evacuar el calor.
conexionado permite hacer los interfaces elctricos internos y externos.
Es una descripcin funcional, no vemos nada fsico. As, podemos disear una
sola vez.
PGINA 55
Para disear un Sistema tan complejo hace falta otras vistas; por ejemplo, la
vista real. La vista real era:
Sistema compuesto por unidades funcionales (UF conjunto fabricado con

funciones hardware y software). Una unidad funcional tendr casi todas las funciones
vistas en la divisin funcional. Cada una de las unidades funcionales tiene casi todo lo
que se nos describe en la divisin funcional. La doble visin complica la definicin,
pero simplifica el trabajo de diseo.
fotocopia 51.5 vuelta izquierda.
Tiene muchos detalles de las unidades funcionales. Una realizacin concreta
del Sistema ser un conjunto de distintas unidades funcionales segn las necesidades
concretas.
Puede haber unidades repetidas. Dentro de la estructura real hay cosas que no
aparecen. Por ejemplo, aqu no est representada la alimentacin ni el sistema de
rearranque o de alarmas (proteccin frente a fallos). Esta estructura es slo de
conmutacin y es redundante. La estructura de alimentacin suele ser sencilla, suele
ser una estructura de difusin.
En el sistema de proteccin frente a fallos, se recogen alarmas cuando una
unidad funcional est muerta. Da la posibilidad de dar un servicio a cada una de las
unidades funcionales.
Todava queda la estructura fsica para describir el Sistema.
PGINA 56
ESTRUCTURA FSICA.
Tiene en cuenta un problema del que no hemos hablado: el empaquetamiento
cmo somos capaces de agrupar los componentes electrnicos en una gran cantidad.
El empaquetamiento se hacen en niveles:
nivel 1 es el ms simple. Dispositivo.

nivel 2 circuito integrado o componente discreto.
nivel 3 placa de circuitos impresos.
nivel 4 armazn (mueble donde se insertan placas y por detrs las conexiones con
circuitos impresos o cableado).
nivel 5 armario.
nivel 6 Sistema.
As hay que partirlo en problemas fsicos. Problema de capacidad fsica a la hora

de dividir el Sistema.
Los problemas del empaquetamiento son:
con cada nivel hay un nmero mximo de componentes del nivel inferior que caben.
limitacin de conexiones exteriores que podemos hacer.
calor que disipa.
En este caso, se asocia una unidad funcional a una placa de circuito impreso. La
particin fsica se intenta hacer por donde menos conexionado haya. Partir por donde el
interfaz sea ms sencillo desde un punto de vista funcional, elctrico y / o mecnico.
El mantenimiento es ms sencillo si no hay cableado por delante.
PGINA 57
Cmo se hace la correspondencia entre los elementos de divisin funcional con

vista real con estructura fsica? La unidad funcional de la vista real se corresponde con
la placa de circuito impreso en la estructura fsica.
En la funcionabilidad se baja varios niveles ms, hasta los componentes. Un
componente es algo que se puede reagrupar en las unidades funcionales. Se disea slo
una vez. Si un componente se disea para todas las funciones, tendr ms coste (cosas
que no son necesarias en la unidades funcionales). Desde el punto del mantenimiento y
de la escabilidad, ser ms barato.
La divisin funcional nos debe permitir una optimizacin: reduccin al mximo
del nmero de los componentes.
Al final, una unidad funcional ser:
fotocopia 51.5 vuelta derecha.
La unidad funcional es un conjunto de componentes hardware y software que
habrn sido identificados en la divisin funcional. Esos componentes son los ltimos
que se disean. Los componentes comunes hardware (interfaz, alimentacin, ...) y
software (proteccin, ...) o componentes especficos hardware (interfaz de transmisin)
y software (interfaz del disco duro). Una unidad funcional puede considerarse como una
integracin de componentes previamente diseados.
Los interfaces hay que disearlos antes que los componentes.
fotocopia 51.6 vuelta izquierda.
Cuando el Sistema es muy complejo hay que usar varias vistas:
fotocopia 51.6 vuelta derecha.

Revisamos las vistas usadas. La vista de producto son todos los elementos
posibles, sus configuraciones, ... Sirve para configurar cada una de sus realizaciones.
La vista funcional deba ser sencilla, poco conexa y sin redundancia. La vista
real puede ser justo al revs.
FIN DEL EJEMPLO.
PGINA 58
Seguimos con el proceso de anlisis. Dentro de la estructuracin, al final se hace

una vez obtenida la estructura:
codificacin de estructura.
asignacin de requisitos.
especificacin del Sistema.
CODIFICACIN.
Para la identificacin de todos los componentes, a parte de un nombre, debe
tener un cdigo, ya que es ms formal. Algo que identifique de forma unvoca ese
elemento.
Debemos ser capaces de identificar todo lo que se debe hacer, sin olvidar nada.
Hace falta hacer una estructura en forma de rbol.
fotocopia 51.7.
Vemos un ejemplo de codificacin. Codificamos incluso la documentacin.
Si no somos capaces de darle un nmero de forma coherente, es que no hemos
hecho bien las cosas. El cdigo refleja la estructura, el orden del Sistema.
Esto sirve, una vez hecha la estructura, para:
asignar requisitos.
seguimientos de requisitos.
planificacin de proyecto vemos lo que hay que ir haciendo.
identificacin de configuracin ser capaz de identificar todos los documentos que
hay que hacer en el proyecto, incluso darle cdigos a los documentos.
ASIGNACIN DE REQUISITOS.
Debemos ser capaces hacer corresponder los requisitos del Sistema a los
requisitos de cada uno de los elementos. Hay que repartir:
requisitos funcionales est casi hecho, habr que concretarlo.

prestaciones algunos se consigue por acumulacin (mdulos mnimos).
parmetros fsicos peso, tamao,... Tendremos ciertas restricciones.
coste es ms complicado de repartir (al menos hasta el primer nivel).
MTTF, TTR factores relacionados con la fiabilidad y la mantenibilidad.
Normalmente se hacen varias alternativas (tiene varias soluciones) y se elige la
mejor.
fotocopia 51.4 derecha.
PGINA 59
ESPECIFICACIN DE SISTEMA.
Estructura del Sistema usando las vistas necesarias.
Especificaciones de Elementos.
Especificaciones de Interfaces.
Plan de Integracin.
2
Plan de Pruebas de Sistema.
y adems...
Diseo conceptual. Decisiones recoger todo el trabajo del diseo
3
conceptual.
Planificacin del Proyecto.
(Plan de Desarrollo, Planificacin del Programa tcnico)
Qu actividades.
Quin las realiza.
Cundo estn terminadas.
Relaciones entre actividades.
Hitos demostrables o de control son maquetas (subconjunto del
Sistema) que sirve para demostrar que funciona.
1
fotocopia 99.1 es un ejemplo de planificacin de proyecto. Lista de

Actividad (con cdigos). Los Eii son los hitos demostrables pruebas
para ver si se ha conseguido la tarea.
fotocopia 99.1 vuelta la planificacin consiste en:
lista (estructurada) de tareas.
diagrama de Gant (temporal) vemos la relacin de qu tareas pueden
ser concurrentes y cules deben esperar a que acabe una tarea previa.
Los hitos se suelen poner cada mes.
Todo esto es el resultado de la fase de anlisis. En la especificacin del
Sistema se refleja todo estos planes.
Plan de Ingeniera de Sistemas.
Descripcin de la Metodologa.
Herramientas y procedimientos.
Documentos conjunto que se generan. Despus de cada actividad,
siempre un documento.
Gestin de configuracin gestin de los documentos: cambios,
actualizacin, ...
Planes especiales:
Plan de Fiabilidad cada uno tendr sus documentos especiales. Se
hace un plano para cada uno.
Mantenibilidad.
Soporte logstico.
Fabricabilidad.
Aseguramiento de la Calidad.
Seguridad.
Control E M.
PGINA 60
Verificacin5.
procesos de verificacin.
o objetivos.
o mtodos de prueba.
o caractersticas de una prueba.
o especificaciones de Prueba.
verificacin en el proyecto.
o pruebas unitarias y de Integracin.
o prueba de Sistema.
o prueba de paso a Explotacin.
o prueba en Explotacin.
Procesos de Verificacin.
Objetivos.
Encontrar palabras como:

errores del proceso, son cosas mal hechas. Se dan en:
o proceso de Desarrollo.
o proceso de Fabricacin.
defectos consecuencia del error, son del Sistema. Los defectos pueden dar fallos o
no. Habr defectos de:
o Desarrollo del Sistema.
o Fabricacin (realizacin).
fallos asociado al Servicio.
Los procesos de verificacin buscan y detectan los defectos para poderles
corregir. Durante el Ciclo de Proyecto, buscamos defectos del Sistema (debidos a
errores de los procesos de desarrollo). Durante el Ciclo de Explotacin, buscamos
defectos de la realizacin (vistos ya). A veces aparecen defectos del Sistema.
Mtodos de prueba.
Podemos clasificar los grupos en tres grandes grupos:

experimentos.
anlisis.
inspeccin.
EXPERIMENTOS.
Es lo ms habitual. Cogemos una realizacin de lo que queremos probar (sistema
completo, elementos, ...) Esa realizacin se llama Sistema Bajo Prueba (SBP). El SBP
hay que meterlo dentro de un entorno: emulacin de entornos. Se intenta hacer otro
sistema que intenta simular el entorno de funcionamiento del Sistema bajo prueba.
5
Verificacin comprobacin de que el diseo est bien hecho.
PGINA 61
Tambin estn el generador de estmulos y la observacin (respuestas y

medidas).
Normalmente, para probar un Sistema hay que hacer muchos experimentos.

Cada experimento simple se le suele denominar un Caso de Prueba. Los Casos de
Prueba sern independientes entre s aunque tengan partes en comn; pues los estmulos
y respuestas son distintos. Cada Caso de Prueba suele incluir:
condiciones.
estmulos.
respuestas posibles a partir de aqu, como hacer el veredicto.
Los problemas que tienen los experimentos:
dispersin de valores de la realizacin bajo prueba (SPB).
precisin de medida.
complejidad validez cuanto ms complejo es el Sistema bajo prueba, el
nmero de casos de prueba, para asegurarnos cierto grado de validez, es cada vez
mayor. Y esto est limitado.
ANLISIS.
Averigua el comportamiento de un Sistema a travs del comportamiento de los
elementos y la estructura. La verificacin de un elemento es ms sencillo, e incluso la
suma de los casos de prueba de todos los elementos puede ser menor que el del Sistema.
No es posible cuando:
experimento no es posible.
experimento es destructivo.
PGINA 62
experimento tiene riesgo de seguridad.

experimento tiene coste inaceptable.
Veamos algunos ejemplos:
resistencia de una estructura de hormign.
capacidad de trfico de una red (entera es imposible).
verificar los requisitos de fiabilidad; por ejemplo, veinte aos.
En estos tres ejemplos estamos seguros que los hacemos bien, por eso es mejor
que el experimento. El anlisis es mejor que el experimento cuando el Sistema es
complejo.
INSPECCIN.
Se usa cuando no se pueden hacer experimentos; por ejemplo, especificacin de
requisitos: tecnologa, verificacin, documentacin.
Caractersticas de una prueba.
Debera guiar el diseo de una prueba:

validez de la prueba.
coste.
tiempo de ejecucin.
VALIDEZ.
En general, es muy raro que una Prueba sea infalible. Los problemas que hay
son:
tiempo y esfuerzo limitado.

precisin de la medida en el experimento.
muestreo en el experimento.
modelo simplificado.
nmero de casos de prueba limitado.
La medida o expresin de esa validez puede hacerse de dos maneras:
cobertura de defectos tpico uso en la prueba de fabricacin de circuitos

integrados. Por ejemplo, capaz de detectar el 90%.
confianza en el veredicto es una probabilidad de que el veredicto sea correcto. Se
usa en negativo: riesgo de veredicto incorrecto (10%, 5%). Suele haber dos riesgo:
o pasa riesgo del consumidor. Un Sistema que pasa unas pruebas pero
puede que no cumpla con los requisitos.
o no pasa riesgo del suministrador. El Sistema est bien, pero la Prueba
dice que no pasa.
PGINA 63
COSTE.
Hay que considerar muchos costes:
coste de ejecucin de la Prueba puede ser el tiempo de ejecucin.
coste del Sistema de comprobacin.
coste de realizaciones algunas veces las Pruebas son destructivas.
TIEMPO DE EJECUCIN.
Puede ser por coste o porque trabajamos con un tiempo limitado.
Al disear las Pruebas, debemos pensar en estas tres cosas. Hay que tener en
cuenta:
no menospreciar las Pruebas. El diseo de Pruebas puede ser igual de complejo que
el diseo del Sistema.
hay que minimizar el riesgo pasa y el riesgo de no pasa, segn coste.
para deducir la validez y el coste habr que hacer una estructuracin,... Hay que
aplicar las mismas ideas a las Pruebas que al diseo, tambin necesita una
estructuracin.
al disear las pruebas hay que tener en cuenta la reutilizacin. Al disear Pruebas,
pensar si se pueden reutilizar para la explotacin.
Especificacin de Pruebas.

Verificacin en el Ciclo del Proyecto.
Pruebas Unitarias y de Integracin.

Pruebas de Sistema.
Pruebas de paso a Explotacin.
PRUEBAS UNITARIAS Y DE INTEGRACIN.
El diseo consiste en tomar el Sistema segn nos lo deja la fase de Anlisis y
dividir los elementos de forma sucesiva hasta reducir su complejidad.
PGINA 64
En el Diseo se especifica los interfaces, las funciones y las especificaciones de

Pruebas de cada elemento. Quien disee un elemento, disea tambin las pruebas que
hay que hacer para saber si el elemento cumple con las especificacin.
Pasada la fase de Diseo, se constituyen los elementos de cierto nivel. Las
Pruebas Unitarias son las pruebas que deben pasar los elementos del ltimo nivel (ms
bajo) que se constituye, para verificar si se cumple su especificacin.
Si sube de nivel, se constituye el elemento y se pasa la Prueba del elemento
diseado. La Prueba de elemento tiene como objetivo ver los posibles problemas de
diseo de interfaces, pues se supone que los fallos internos del elemento los detecta las
Pruebas Unitarias. Las Pruebas de Integracin son las pruebas de elementos de otros
niveles orientados a verificar los elementos de ese nivel, suponiendo que los elementos
de ms bajo nivel estn bien hechos.
La eleccin de la estrategia de integracin ms adecuada se har en funcin de la
validez y el coste.
Lo que hemos contado es lo ms conservador y lo ms seguro. Tambin se
puede minimizar las Pruebas Unitarias y de Integracin (ensamblar sin mirar),
reduciendo el coste pero encareciendo las Pruebas de Sistema.
Normalmente nos quedamos en el punto intermedio, Plan de Integracin; que
busca un compromiso de las estrategias de integracin6:
nmero de integraciones.
de funcin de cada una.
Hay varias estrategias de integracin, que no son stas. Por ejemplo, en un
Sistema software, construir un Sistema en el primer nivel (ms alto) y sus interfaces,
pero sin ms funciones en los elementos que las interfaces. Se van incorporando cada
vez ms funciones, integrndolas. Podemos detectar y corregir problemas de la
estructura,... Esto se llama desarrollo incremental. Son refinamientos sucesivos de cada
uno de los elementos. Pero la estructura est desde el principio.
Debemos tener el Sistema completo construido e integrado (es decir, que no
tenga defectos). La verificacin en detalle de todos los requisitos se hace con el Sistema
construido:
Pruebas de Sistema.
Suelen ser Pruebas desde fuera, de cajas negras.

El objetivo suele ser verificar el cumplimiento de los requisitos. Para ello ser
necesario que los requisitos sean formales (claros y no ambiguos). Por eso se verifican
las especificaciones. Tambin, como objetivo, tenemos que evaluar el Sistema, ya que
los parmetros deben estar dentro de las tolerancias. Veremos:
Integracin juntar varios elementos y hacer una prueba.
PGINA 65
planificacin y preparacin.
secuenciamiento de las Pruebas.
verificacin de Requisitos.
Pruebas en condiciones lmites.
PLANIFICACIN Y PREPARACIN.
Hay que hacerlo en la fase de anlisis, aunque se ejecuta ahora. En la fase de
anlisis hay que hacer el Plan de Pruebas del Sistema, hacer un planning de las pruebas,
asignando recursos, cundo, objetivos,... Es un plan de actuaciones. Es importante
detectar, si hace falta, sistemas que hay que adquirir o disearlo. Por eso hace falta
hacerlo tan pronto, para saber los recursos necesarios.
La preparacin se hace durante la fase de diseo y de fabricacin (despus de
fase de anlisis). Lo que se hace:
definicin de Maquetas (realizaciones del Sistema sobre las que se realizan las
pruebas).
especificaciones de Pruebas de Sistema conjunto de Pruebas suficiente para
verificar los requisitos, con costes razonables.
herramientas de Prueba: definir, adquirir, disear.
SECUENCIAMIENTO DE LAS PRUEBAS.
Si hacemos una prueba y el Sistema no va, debemos corregir el defecto que
hayamos encontrado, y verificar que se cumple. El proceso habitual es que cada vez que
se detecta un defecto, se debe corregir. Habremos estropeado otra cosa? Debemos
comprobar que todo vaya bien.
Se suele hacer una cosa intermedia que minimiza el coste de las Pruebas. Las
Pruebas se hacen de forma secuencial y, al encontrar un error, se informa y sigue
hacindose. En determinados instantes de la secuencia, se vuelve al principio de las
pruebas. Esta estrategia estar en el plan de Pruebas.
Se hablan de tres tipos de pruebas, en relacin con esa secuencia:
Pruebas de progresin las Pruebas que se hacen por primera vez. Si falla,
hacemos una peticin de cambio.
Pruebas de correccin despus de hacer el cambio, hacemos Pruebas para ver si el
cambio ha corregido el fallo detectado.
Pruebas de regresin Pruebas ya hechas, como progresin. Se vuelve a hacer
cuando hay un cambio en el Sistema y quiere verse que no produce nuevos fallos.
Al final, el Sistema debe cumplir todos los requisitos, en su estado final
(corregidos todos los fallos).
VERIFICACIN DE LOS REQUISITOS.
Ya hablamos del Sistema completo integrando:
PGINA 66
Pruebas funcionalesse hace con experimentos de estmulos respuesta (se ve). Se

hacen en condiciones normales, la funcionalidad se verifica en condiciones normales:
ambientales y de carga (de trabajo). Verificamos los requisitos. Las pruebas
funcionales se secuencian:
o Pruebas por separado.
o Pruebas conjuntas el Sistema debe cumplir con todos los requisitos a
la vez.
o situaciones normales.
o situaciones anmalas.
Pruebas de prestaciones verificamos que los parmetros dentro de los requisitos y
evaluamos esas prestaciones. Se hace:
o experimentos (con medida).
o condiciones normales.
o se mide las prestaciones en un subconjunto normal de funcionalidad.
o se mide parmetros por separado.
o se mide parmetros por conjunto.
Estas Pruebas se suelen hacer a la vez con las Pruebas de Control de
Sobrecarga.
A travs del conjunto de los interfaces le podemos pedir al Sistema ms
trabajo del que suele hacer. Los Sistemas deben poder soportar este trabajo mximo
y, si no, se saturan.
Pruebas de condiciones ambientales ver si el Sistema soporta los lmites de
temperatura, humedad, ... Se suele hacer las pruebas:
o en funcionamiento vemos si el Sistema, en las condiciones lmites
ambientales, no falla.
o retirado del Servicio detectar que no se produce defectos en ambientes
extremos (que no hay degradacin).
No se hace con todas las combinaciones de funciones, sino con un conjunto de
funciones normales y en condiciones:
o funcin normal.
o carga normal.
o carga sobrecargada.
Pruebas de Requisitos de Documentacin se hace por inspeccin. Esta inspeccin
no es demasiado fuerte pues se comprueba que estn los documentos, no su
contenido. Aunque a veces, s se comprueba los documentos. Se suele hacer un
muestreo de contenidos.
Pruebas de Fiabilidad y Mantenibilidad si el Sistema es sencillo, se hace mediante
experimentos. Se pone en condiciones de esfuerzo (sobrecarga, lmites
ambientales,...) y mediante modelos matemticos sacamos la Fiabilidad; poniendo,
tambin, muchas realizaciones del Sistema.
En los Sistemas complejos se recurre al Anlisis. Conociendo la estructura de
Fiabilidad (entre los elementos), sabemos cules son los parmetros de Fiabilidad.
Con la Mantenibilidad pasa igual, se hacen estimaciones. Experimentos:
demostracin de Fiabilidad y Mantenibilidad.
Pruebas en condiciones lmites hay que verificar que el Sistema funcione bien
fuera de las condiciones normales y soporte las condiciones lmites especificadas en
los requisitos.
Hay que diferenciar:
condiciones de entornos ya hemos hablado de ellas.
PGINA 67
condiciones de carga de trabajo dependiendo del tipo de Sistema, la carga

puede ser distinta. Por ejemplo, en un conmutador ser el trfico de
conmutacin o la carga en una C.P.U.,... Hay que probar con carga alta
(porque la fiabilidad disminuye, pero aqu no nos interesa) ya que puede que
el Sistema no funcione. Otro problema que no nos interesa ahora sera la
fiabilidad.
Pruebas fuera de las condiciones normales tenemos:
pruebas de sobrecarga se hacen ms all de las condiciones normales, por
encima de la nominal, pero sin llegar al lmite (dentro de los lmites). Hay
que decidir una combinacin de pruebas de sobrecarga. Compruebo que
cumple con los requisitos.
pruebas marginales se hacen por encima del lmite permitido (ms all).
Sirven para:
saber la sensibilidad del Sistema.
conocer los lmites reales su distribucin. Podemos calcular el riesgo
de que las unidades no cumplan (a travs de estudios estadsticos).
A veces, las pruebas marginales son destructivas. Por ejemplo, en un
puente. Se har una anlisis pero no una prueba marginal.
Pruebas de paso a Explotacin.
Estas pruebas pertenecen al proyecto, aunque no est muy claro. Las pruebas del
Sistema se disea dentro del proyecto, gente que participa en l. Puede ocurrir, por
tanto, que el que disea las pruebas no sabe cmo va a funcionar el Sistema y puede que
le d poca importancia a un parmetro que ser primordial en su uso comercial.
Estas pruebas de paso a explotacin estn diseadas por los usuarios, gente que
es externa al proyecto. Intentarn detectar los fallos comunes provocados por el uso del
Sistema. A veces, se detectan problemas de definicin o de anlisis.
Hay dos casos, segn el tipo de proyecto:
Sistema a medida si el cliente que existe conoce la necesidad, realiza las
pruebas se hacen las PRUEBAS DE ACEPTACIN el usuario acepta el Sistema
como bueno.
fabricacin masiva como el cliente es annimo, es el marketing quien decide estas
pruebas se hacen las PRUEBAS ALFAS Y BETAS, hechas por el usuario.
PRUEBA DE ACEPTACIN.
La instalacin consiste en mover el Sistema a otro sitio, en su entorno de
verdad, no en el simulado. Se suele hacer con una documentacin.
A continuacin, un usuario hace las pruebas de aceptacin. Las pruebas de
aceptacin a veces las hace el propio usuario y otras se negocian. Para ello el
usuario utiliza el manual de usuario, que es un documento que se hace. Estas
pruebas suelen ser ms fciles que las pruebas del Sistema, pero puede ser que el
Sistema tenga defectos. Si las pasa, el Sistema llega a la explotacin.
PGINA 68
PRUEBA ALFA Y BETA.

Cuando se trata de fabricacin masiva, puede que el que realice el proyecto no
provea bien qu uso se le va a dar el Sistema.
Hay que comprobar, tambin, que la fabricacin est bien hecha, pues se suele
disear un proceso de fabricacin (que est orientado a que la fabricacin sea eficiente
desde el punto de vista econmico), tanto hardware como software.
As el proceso de fabricacin es:
Al principio es el mismo: pruebas del Sistema. Pasadas stas, se hacen las
pruebas alfas, que son pruebas de usuarios (tambin tendrn manual de usuario) de
dentro de la organizacin pero fuera del proyecto. Si es hardware, se hace un
modelo de ingeniera. Un modelo de ingeniera est hecho con las
especificaciones de fabricacin (informacin con la que se fabricar todas las
rplicas, se hacen unos pocos modelos de ingeniera).
En estas pruebas se detectan problemas de uso y errores del proceso de
fabricacin (cometidos al optimizar econmicamente la fabricacin). A veces,
tambin, se hacen pruebas de Sistema sobre el modelo de ingeniera, si es software.
En las pruebas beta, los usuarios son externos a la organizacin. Para ello se
hace una preserie (nmero de unidades se eleva). La preserie se hace con la misma
documentacin que se hace la fabricacin en serie, tal y como despus se vender,
con el mismo proceso final de fabricacin. Tendr y se comprobar el manual de
usuario e instalacin. Los usuarios sern externos, pero no annimos. stos se
comprometen a dar informacin de los problemas que encuentren, a cambio de ser
los usuarios primeros del producto.
Pruebas de Explotacin.
pruebas de fabricacin se hacen a cada una de las unidades, para probar que el
proceso de fabricacin est bien.
pruebas de instalacin una vez particularizado el Sistema a un entorno
determinado, se comprueba que est bien.
pruebas de mantenimiento cada vez que se hace una accin de mantenimiento
correctivo o preventivo, hay que comprobar que el Sistema est bien.
Estas pruebas se parecen a las otras, en los objetivos:
validez (confianza) en las pruebas.
coste.
tiempo de ejecucin.
PGINA 69
Las particularidades que hay:

los requisitos de costes y tiempo de ejecucin son ms rgidos.
mantenimiento en campo las pruebas de instalacin y mantenimiento hay que
hacerlo donde las pruebas se van a usar.
Una cosa importante es conseguir la reutilizacin de pruebas. El objetivo no es
detectar errores del Sistema, que ya est hecho. Tratamos de detectar errores del
proceso, slo verificar eso; por eso es ms sencillo.
Hasta aqu, los procesos de definicin, de anlisis, de diseo y de verificacin

son los procesos de ingeniera (tcnicos). Ahora vienen los procesos de control del
proyecto.
Control del Diseo.
Veremos mtodos cuyos objetivos sern:

evitar errores habituales.
detectar los errores cometidos (cuanto antes).
evitar duplicar trabajo.
Los mtodos que veremos son dos:
Reglas de Diseo elaboracin y usos.
revisiones formales.
REGLAS DE DISEO.
Sirven para evitar errores habituales y duplicacin de trabajo, tambin para el
entendimiento entre diseadores. Se usan:
recetas soluciones probadas a problemas habituales de diseo. Por ejemplo, el
diseo hardware de las placas de circuitos impresos: separacin de pistas de cobre,
ancho, diafona de los hilos. En hardware, el diseo elctrico, como conectar una
familia lgica con otra (no disearlo cada usuario, que ya est hecho, pues siempre
igual). La alimentacin o reset. En software, puede ser con los algoritmos de
bsqueda.
Quien hace las pruebas, invierte mucho tiempo en hacerlas bien. El diseador
no tiene tiempo y no las hara bien.
guas de las herramientas del desarrollo las herramientas son, cada vez, ms
grande y ms complicadas de usar ya que van englobadas ms funciones. Si usamos
herramientas exteriores, estn hechas con un propsito general y tendran muchas
cosas. As, que alguien se dedica a estudiar esas herramientas y har una gua
simplificada con las cosas que nos interesa. A veces, tambin es una gua con
restricciones (no usar algo para asegurar que la probabilidad de errores es menor).
estilos de Representacin y Documentacin los Sistemas estn definidos en la
documentacin y hay muchas formas de representarlos (distintos estilos). Por
PGINA 70
ejemplo, diagrama de electricidad. Sirve para que todos entendamos cualquier

documento y se obliga a cierta estructuracin.
restricciones a los diseadores (no pueden hacer lo que quieran) por ejemplo, en
diseo hardware, restringir los componentes que podemos usar por diversos motivos
(fiabilidad, stock, ...).
Todas estas cosas se plasman en manualidades de diseo (hardware, software,
...).
REVISIONES FORMALES.
El objetivo es detectar errores en el proceso de desarrollo y poder tomar acciones
correctoras, lo antes posible.
Es una auditoria sistemtica estructurada realizada por un grupo de personas
sobre el resultado de alguna actividad del proyecto.
Un diagrama del proceso de una revisin, podra ser:
El ponente es el responsable de la actividad. El responsable es el encargado de la

revisin, que cumpla con su misin. Los grupos de revisin son personas exteriores que
revisan la actividad. Suelen ser interdisciplinares.
La metodologa define el cuadro grande. El xito de una revisin depende de que
la lista de comprobacin sea suficiente (contenga los errores ms frecuentes). Depende
del grupo y, de otra cosa muy importante, la actividad positiva del ponente (que no se
ponga rojo), es el que ms ayuda a detectar los errores, si acepta ayuda y sugerencias del
grupo.
PGINA 71
Hay dos tipos de revisiones formales:

Revisin de Diseo se revisa el proyecto globalmente. Se hace al final de la fase
de anlisis (visto en la fotocopia 51.4 derecha). A veces, se hace una Revisin de
Diseo antes, en el Diseo conceptual.
A lo largo de la fase de Diseo, se hacen varias Revisiones de Diseo (dos o
tres):
se hace una cuando el Diseo est al 50%.
otra revisin al final, cuando est hecho todo el trabajo. Tambin se
hace una revisin de los documentos, cuando estn todos los
documentos.
La Revisin debe ser macroscpica, no perderse en el detalle. Se revisa, a
grandes rasgos:
la funcionalidad.
los Interfaces que estn bien diseados.
asignacin de Requisitos (parmetros) que se cumplan.
Normas verificarlas.
Documentacin que se estn haciendo los documentos.
Planes especiales fiabilidad,
soporte,
mantenibilidad,
fabricabilidad, ...
Son cosas generales, de hecho, el grupo que hace la Revisin de Diseo suele
ser el jefe de proyecto, gente que particip en la definicin y el anlisis (gente capaz
de analizar el proyecto, en general) y especialistas en fiabilidad u otros temas.
Respecto a la Asignacin de Requisitos, tambin se le denomina
seguimiento de prestaciones o seguimiento de parmetros. Hay que cumplir las
especificaciones y los parmetros cuantitativos. Esto se hace en una tabla:
R. D. 1
R. D. 2
parmetro 1
...
...
Los parmetros estn calculados con una tabla de los elementos del Sistema. A
cada elemento se le pone el requisito asignado. En las sucesivas Revisiones de
Diseo sustituimos ese requisito asignado por el valor que tengo o una estimacin de
ese valor. Se va consiguiendo mejores estimaciones de los valores reales.
As Comprobamos que no superamos lo especificado: tamao, coste,
consumo,... Tenemos que comprobar que el requisito total se cumple y si no se
consigue, se toman medidas.
revisin de entrega de documentacin los documentos hechos del Proyecto se
entregan a la Organizacin. Pero para que se pueda entregar debe pasar una revisin
formal del documento. Se hacen revisiones formales de los documentos de una
actividad (un conjunto de documentos). No son exhaustivos, aunque se exija este
formalismo. Habr listas de comprobacin para cada tipo de documento. Como
ejemplos tenemos las prcticas o la fotocopia 99.3. Muchas veces se revisa las cosas
que estn hechas, que se cumplen las reglas de Diseo y algunos errores tpicos que
se cometen.
PGINA 72
Relacionados con estos dos tipos de revisiones formales estn:

coste de los errores intenta detectar los errores lo antes posible, pues el coste de su
correccin crece conforme ms tiempo tardamos en detectarlos. Por ejemplo, el
condensador.
Cunto esfuerzo debemos dedicar a la revisin? Hay un compromiso entre el

esfuerzo de revisin y el coste de los errores. Este esfuerzo (su dedicacin) surge de
la experiencia.
Las revisiones y Reglas de Diseo son necesarias.
mejorar la Metodologa las listas de comprobacin y las Reglas de Diseo se
elaboran mediante una metodologa. Esta metodologa se puede mejorar con estas
revisiones. Si detectamos un error, las acciones correctivas que se toman para corregir
el error y una reflexin: por qu hemos hecho ese error? Por qu no se ha detectado
antes? Se podra haber evitado el error con otra regla de diseo? Se podra haber
detectado el error modificando la Revisin de Diseo o con otra persona?
De la reflexin viene una mejora de las reglas de Diseo y de los
Procedimientos de Revisin. Todo esto est enfocado a no cometer el mismo error
(experiencia de lo bueno: organizacin ms experta).
Gestin de Configuracin.
concepto de configuracin y de Gestin de Configuracin.

actividades de Gestin de Configuracin.
Concepto de Configuracin y de Gestin de Configuracin.
El trabajo realizado debe recogerse en documentos, ya que un trabajo hecho no

plasmado en un documento, o se queda en la memoria del que lo hizo o se queda en
notas informales. Toda esa informacin se escapa a la organizacin, al resto de
personas.
PGINA 73
El objetivo del proyecto es disear el Sistema (no construirlo), hacer

documentos que describan al Sistema; este es el objetivo.
As, la Configuracin del Sistema es el conjunto de documentos que definen el
Sistema en un momento dado (es algo dinmico).
La Configuracin empieza con un conjunto de documentos: Especificacin del
Sistema. A partir de esto, la Configuracin va cambiando, va teniendo ms documentos
y esos documentos pueden cambiar.
La Gestin de Configuracin es un conjunto de procedimientos y actividades.
Esos procedimientos y actividades tienen como objetivo que la Configuracin vaya
creciendo de manera ordenada y controlada.
Ordenada quiere decir que el conjunto de documentos tiene una estructura, un
orden. Controlada quiere decir que los documentos que forman parte de la
Configuracin deben haber pasado una revisin, deben estar controlados. Tambin debe
estar controlado cmo se distribuye esos documentos.
Actividades de Gestin de Configuracin.
Se suele definir cuatro tipos de actividades:
identificacin de configuracin.
control de configuracin.
generacin informes de Estado de configuracin.
auditorias de configuracin.
IDENTIFICACIN DE CONFIGURACIN.
Genera una lista con todos los documentos necesarios para definir una Sistema.
Se suele hacer al principio.
Estos documentos hay que identificarlos antes que existan, para:
Generacin de documentos si no se identifica, a lo mejor no se hace.

Control de documentos cada diseador hace el documento y no lo entrega.
Uniformidad en la documentacin al tener identificado lo que hay que hacer.
Conseguir una estructura en el conjunto de la documentacin.
fotocopia: Estructura de la documentacin.

A veces se usan, por ejemplo, tres niveles de edicin:
Edicin cambios en la documentos debido a un error en la descripcin.
Versin cambio de funcionalidad.
Entrega Sistemas completos que han pasado las Pruebas de Sistema.
En realidad existen muchas versiones y ediciones. La regla de oro es evidente:
incrementar la edicin al hacer un cambio.
PGINA 74
CONTROL DE CONFIGURACIN O CONTROL DE CAMBIO.

Los documentos, que forman parte de la configuracin, se distribuyen. A veces
necesitamos hacer cambios en los documentos, por diversos motivos:
por errores.
por mejoras.
por nuevos requisitos.
cambios de la tecnologa.
El control de configuracin es el conjunto de actividades y procedimientos para

documentar todos los cambios en la configuracin y asegurar que los cambios han sido
aprobados.
En un proyecto siempre hay muchas cambios, hay que admitirlos pero
controlarlos. El origen de un cambio puede ser:
responsable (de un elemento o un documento):
entrega primera edicin.
detecta un error.
mejora antes cumpla requisitos, ahora mejor.
otros:
error en texto de documento.
propuesta de mejora.
error en el Sistema.
nuevos requisitos.
Los cambios se proponen, luego podrn ser aprobados por un grupo de control.
El control de configuracin se basa en la peticin de cambio.
El Comit de Control de Cambio ser quien apruebe los posibles cambios. Sus
funciones son el Anlisis y la Aprobacin o Denegacin del cambio.
Ni siquiera el responsable de un elemento est libre de hacer las peticiones de
cambios. Esto es debido a que los responsables de un elemento quizs propongan
mejorar un elemento, pero que a la vez empeore otra cosa.
El Comit est formado por las mismas personas que realizan las Reglas de
Diseo, es decir, que tiene una visin global del proyecto.
Veamos como el Comit realiza el anlisis, segn el origen de cambio:
ordena clasifica por orden de mayor o menor importancia. Se dedica ms esfuerzo
a ver si se aprueba o no la peticin segn la importancia del cambio. As, por
ejemplo, de mayor a menor importancia tenemos los siguientes cambios:
coste.
planificacin.
un interfaz.
funcionalidad de elemento.
corregir error de un elemento.
PGINA 75
corregir error de texto.
PC peticin de cambio.

C.C.C. Comit de Control de Cambio.
NC notificacin de cambio. Dice en qu consiste y el porqu del cambio. Parecido a
la peticin de cambio. Va acompaado del documento real.
OC orden de cambio.
PGINA 76
Se genera una peticin de cambio al detectar un error o por un nuevo requisito.

El Comit de Control de Cambios no aprueba todas las peticiones de cambio, pues
habra que cambiar una gran parte del proyecto. Si se aprueba la peticin de cambio, el
Comit averigua qu hay que cambiar y lo comunica mediante una orden de cambio. El
responsable genera un documento modificado que debe ser aprobado; va acompaado
por una orden de cambio.
fotocopia de solicitud de cambio.
fotocopia de orden de cambio.
INFORMES DE ESTADO DE LA CONFIGURACIN.
Una de las funciones de la Gestin de Configuracin es saber, en cada instante,
los estados de los documentos del proyecto: cules hay, versiones, ... Vamos, el estado
de la configuracin.
Entonces la Gestin de Configuracin debe ser capaz de hacer un informe de
Estado de la Configuracin, que es:
la lista de documentos identificados desde el principio y otros que surjan del
desarrollo del proyecto.
indicar si han generado o no.
cul es la versin vigente.
Sirve para que la gente, a quien se les distribuye los documentos, sepa cul es el
documento vigente (por si se pierde alguno).
No deben circular los documentos no oficiales porque deben pasar por la
Gestin de Configuracin, que establece su control. Tambin sirve como documento de
entrada a las revisiones de diseo.
Hay que hacer un registro de los cambios, para poder hacer el informe de Estado
de la Configuracin. En l aparece la historia de cada uno de los documentos, aunque
nada sobre su contenido.
AUDITORIA DE CONFIGURACIN.
Es una revisin formal que afecta al proceso de Gestin de Configuracin. Su
propsito es verificar que se est haciendo y que se cumple con sus objetivos. La lista
de comprobaciones de la auditoria:
verificar la documentacin del elemento se comprueba que todos los documentos
entregados tienen todo lo definido en l. No nos metemos en su contenido.
verificar el proceso de control de cambios ver si las peticiones de cambio se han
traducido en nuevos documentos y que esos nuevos documentos reflejan esos
cambios.
estado de Configuracin verificar si el informe de Estado de la Configuracin
dice la verdad.
PGINA 77
estado de la distribucin verifica que la gente tiene y usa el documento que se

dice en el informe de Estado de la Configuracin.
En la Revisin de Diseo se puede meter estas Auditorias, pero tambin se debe
seguir haciendo en la Explotacin.
PGINA 78
Tema 5: Modelos de calidad.

Normalizacin de la calidad.
Modelos no secuenciales del Proceso de Desarrollo.
Modelos de madurez evolucin o mejora de un Proceso de Desarrollo.
Normalizacin de la calidad.
El punto de partida de un Proceso de Desarrollo es una Necesidad. El Proceso

tiene como objetivo un Sistema, del cul se harn realizaciones (sistemas). Lo vemos
grficamente:
As, actualmente entendemos calidad como:

grado de satisfaccin del usuario del Sistema, que es quien recibe el servicio.
grado de satisfaccin del Suministrador del Sistema: que todos los procesos se
hagan de manera eficaz y econmica.
Tambin incluye mantenimiento, soporte, ...; no slo los procesos de
fabricacin.
La Normalizacin se usa para facilitar la transferencia entre suministrador y
usuario; para que las partes que transfieren algo, dejen claro que se transfiere.
Hay organismos que normalizan los procesos de desarrollo para certificar que se
cumple con unos mnimos, normalizando as la calidad.
PGINA 79
As aparecen los Sistemas de Calidad. Aqu, los elementos son procesos

humanos divididos en procedimientos. Los elementos pueden ser de varios niveles.
Cada elemento tiene una funcin bien definida, sin existir repeticin de funciones. Los
elementos estn relacionados entre s. Por ejemplo, ISO9000 define un Sistema de
Calidad, su ttulo es Gestin de la Calidad y Aseguramiento de la Calidad. Con esta
norma se sabe que se cumplen unos mnimos.
Las normas ISO9000 definen un conjunto de procedimientos, sus nombres y no
de forma detallada (no cmo se hace), pero s define unos mnimos. Cada organizacin
disea los procedimientos para que cumpla la ISO9000.
Las normas ISO9000 exigen que los procedimientos diseados por la
organizacin estn escritos y que se cumplan (di lo que haces y haz lo que dices).
Hay varios grados de cumplimiento de esta calidad, que dependen del nmero de
procedimientos que estn controlados. Hay varias normas, segn estos grados de
cumplimiento:
Inspeccin de Entrada
Ensayos finales
Instalacin
Compra
Soporte
Mantenimiento
Desarrollo
ISO9003 ISO9002 ISO9001

X
X
X
X
X
X
X
X
X
X
X
X
X
La ISO9001 controla todos los procedimientos, desde la necesidad hasta la

explotacin.
Modelos no secuenciales del Proceso de Desarrollo.
Veremos qu problemas tiene el modelo secuencial visto hasta ahora:

decisiones tempranas a tomar en la fase inicial del proyecto hay que tomar
decisiones; muchas de ellas hay que tomarlas con informacin limitada, por lo que
tomamos malas decisiones y esto luego tiene un coste:
errores que pasan.
coste de los errores que se detectan.
caractersticas olvidadas durante el diseo es difcil seguir todos los requisitos.
Se suele poner ms esfuerzo en conseguir algunas caractersticas (funcionalidad,
coste, ...) que en otras (fiabilidad, ergonoma, ...). Se pueden descubrir estos olvidos
muy tarde en el proceso.
Para solventar estos problemas, hay otros modelos:
modelos iterativos.
modelos concurrentes.
PGINA 80
MODELOS ITERATIVOS.
Se hace el diseo sobre iteraciones sucesivas, aproximndose poco a poco al
Sistema requerido:
Cada iteracin requiere menos tiempo y esfuerzo que el modelo secuencial, pero
en global no. El objetivo aqu no es el Sistema completo, sino una simplificacin del
mismo. Entonces las decisiones tomadas aqu son mejores.
En la primera iteracin estn los requisitos ms crticos e importantes. Cosas
tpicas: diseo de interfaces, ...
MODELOS CONCURRENTES.
Las pruebas se hace en casi todo el proyecto, la toma de decisiones (anlisis)
tambin se va haciendo durante todo el proyecto, ... Los procesos de desarrollo son un
conjunto complejo de procesos que empiezan escalonadamente, pero luego todos
funcionan a la vez y se van pasando informacin los unos a los otros. Es un modelo ms
realista. Veremos algunos ejemplos:
Ingeniera concurrente evita desatender algunas caractersticas. Se trabaja en
grupos de trabajo:
PGINA 81
Proceso Unitario de Desarrollo los procesos son flujos de trabajo (cosas que se
hacen). Se propone el modelo:
El tiempo va hacia la derecha. A lo largo del tiempo, los flujos de trabajo

empiezan y siguen.
El flujo de trabajo es de esfuerzo variable en el tiempo: al principio habr
mucho y luego disminuye.
Conseguimos que haya alguien responsable de un proceso desde que empieza
hasta que se acaba.
fotocopia 123.1.
Modelo de Ingeniera de Sistemas promovido por SEI CMU usa un modelo
complejo pero muy estructurado, con mucho detalle. Ha diseado un Sistema para
hacer un desarrollo de Sistema. Ha identificado dieciocho procesos, que se reparten
en tres grandes elementos del Sistema. Cada proceso est definido con bastante
detalle. No hay ninguna secuencia entre los dieciocho procesos.
Vemos los procesos en la fotocopia 121.1 vuelta vemos los tres grandes
elementos (quedarse slo con el modelo): procesos de ingeniera (centro), procesos
de control del proyecto (derecha) y procesos de la organizacin (izquierda).
Se organiza en dos niveles, tres grupos, como vemos las fotocopias:
fotocopia 121.2 estn escrito por orden alfabtico, pues no es importante el orden
de ejecucin.
fotocopia 5.1.
fotocopia 5.2.
Modelos de madurez.
Una organizacin es ms madura cuando sus Procesos son mejores, y esto

sucede cuanta ms metodologa usa y cuanto ms formalizados estn los Procesos, y
todo esto debe estar en los documentos.
La madurez se puede normalizar, por ejemplo la SEI CMU normaliza un
modelo que llama CMM (Capability Maturity Model). Este modelo tiene dos partes:
una la acabamos de ver y la otra es de evolucin de madurez.
PGINA 82
Define procesos y procedimientos cuyo objetivo es mejorar los Procesos de

Diseo del Sistema.
Vemos los niveles de madurez que proponen:
nivel 0 no se hace ninguno de los dieciocho procesos.
nivel 1 se hacen los dieciocho procesos, pero informalmente. Es decir, es una
ejecucin informal de todos los procesos.
nivel 2 se hacen los dieciocho procesos y alguien los supervisa. Es una ejecucin
planificada y supervisada.
nivel 3 formalizacin en documentos de los procesos: ISO9000.
nivel 4 control cuantitativo, hay que medir si los procesos van bien o mal.
nivel 5 mejora continuada.

IDST

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

IDST

Hochgeladen von

Copyright:

Verfügbare Formate

E.T.S.

INGENIERA DE DESARROLLO DE SISTEMAS DE TELECOMUNICACIN

SISTEMAS COMPLEJOS Y SU REPRESENTACIN.

CARACTERSTICAS DE LOS SISTEMAS.

METODOLOGA DEL PROCESO DE DESARROLLO.

INGENIERA DE DESARROLLO DE SISTEMAS DE TELECOMUNICACIN

INGENIERA DE DESARROLLO DE SISTEMAS DE TELECOMUNICACIN

Concepto de ingeniera de Sistemas.

es una disciplina tcnica.

El proyecto es una particularizacin de esa actividad de desarrollo, es un caso

INGENIERA DE DESARROLLO DE SISTEMAS DE TELECOMUNICACIN

El modelo ser secuencial:

Las funciones de cada uno de estos elementos:

definicin define los objetivos del proyecto. Se habla de pasar de la necesidad a

INGENIERA DE DESARROLLO DE SISTEMAS DE TELECOMUNICACIN

se define el servicio a ofrecer, pero no el Sistema (vendr despus).

identificar las alternativas de tecnologa, divisin y asignacin de requisitos

planes de pruebas probar.

diseo (no complejo).

INGENIERA DE DESARROLLO DE SISTEMAS DE TELECOMUNICACIN

integracin los elementos fabricados y comprobados; se juntan y prueban los

Se dice que estas actividades no son de ingeniera de sistemas. Hay poca

Explotacin del Sistema.

fabricacin hace realizaciones (sistemas).

operacin control humano necesario para que un sistema artificial ofrezca el

INGENIERA DE DESARROLLO DE SISTEMAS DE TELECOMUNICACIN

a medida (llave en mano) el usuario es alguien conocido y es quien promueve el

en general, a veces una (carretera) o muchas (sucursal bancaria).

INGENIERA DE DESARROLLO DE SISTEMAS DE TELECOMUNICACIN

Tema 2: Sistemas complejos y su realizacin.

divisin (en partes).

DIVISIN (EN PARTES).

INGENIERA DE DESARROLLO DE SISTEMAS DE TELECOMUNICACIN

La divisin no es nica, por lo que hay que buscar la ms adecuada. Lo general

Vamos a intentar mejorar el Sistema. Los problemas que tiene es que se

INGENIERA DE DESARROLLO DE SISTEMAS DE TELECOMUNICACIN

Tiene el mismo problema: alto riesgo de fallo y desperdicio de agua. Aadimos

El almacn, cuando se le pide, entrega para aumentar el contenido. Cuando el

Sera un Sistema de suministro con almacenamiento; hemos mejorado el servicio

INGENIERA DE DESARROLLO DE SISTEMAS DE TELECOMUNICACIN

El elemento funcional permite hablar en un lenguaje nico (abstracto), aunque

Los accesos estarn enlazados con terminales. En la descripcin interesar dar la

la calculadora de programa almacenado (John von Neumann, 1.945) la primera

INGENIERA DE DESARROLLO DE SISTEMAS DE TELECOMUNICACIN

el Sistema de telefona es el Sistema mundial. Tiene cuatro grandes funciones:

la interconexin de sistemas abiertos (1.977) La estructura es sencilla.

INGENIERA DE DESARROLLO DE SISTEMAS DE TELECOMUNICACIN

ismeros de qumica inorgnica mismos elementos pero cambiando el orden en

arriba representacin de seales.

Hay muchas ms interacciones que podemos considerar: transferencia de calor,

INGENIERA DE DESARROLLO DE SISTEMAS DE TELECOMUNICACIN

fotocopia 33.3 abajo

Habitualmente, el diseador no verifica.

a) vista de usuario se considera el comportamiento exterior, define la interaccin del

INGENIERA DE DESARROLLO DE SISTEMAS DE TELECOMUNICACIN

INGENIERA DE DESARROLLO DE SISTEMAS DE TELECOMUNICACIN

El diseador podr hacer su trabajo. Lo importante es no tener en cuenta todas

estructura fija Sistema que al cambiar la estructura no cumple la funcin

facilidad y economa de fabricacin.

EJEMPLO: MUEBLES DE CASA.

INGENIERA DE DESARROLLO DE SISTEMAS DE TELECOMUNICACIN

La particularizacin disea la vista real adaptada a una necesidad concreta. La

As es como se conectan los usuarios para la toma de energa.

Vemos que cambian automticamente el sentido de distribucin de la energa