IDST

E.T.S. INGENIERA DE TELECOMUNICACINUNIVERSIDAD DE MLAGAMLAGA

INGENIERA DE DESARROLLODE SISTEMAS DE

TELECOMUNICACIN

5 CURSO

INGENIERA DE DESARROLLO DE SISTEMAS DE TELECOMUNICACIN PGINA 2

TEMARIO

TEMA 1: INTRODUCCIN.

TEMA 2: SISTEMAS COMPLEJOS Y SU REPRESENTACIN.

- Sistemas.- Estructuras.- Interfaces.

TEMA 3: CARACTERSTICAS DE LOS SISTEMAS.

- Procesos de Explotacin.- Caractersticas generales.- Caractersticas especiales.- Fiabilidad.- Mantenibilidad.

TEMA 4: METODOLOGA DEL PROCESO DE DESARROLLO.

- Definicin.- Anlisis.- Diseo.- Verificacin.- Control del Diseo.- Gestin de Configuracin.

TEMA 5: SISTEMAS DE CALIDAD.

- Normalizacin de la Calidad.- Modelos concurrentes.- Modelos de madurez.


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 quecomponen el Sistema. Un elemento vendr definido por su funcin, lo que el elementoes capaz de hacer. Los elementos relacionados y el Sistema tienen una funcin global oun comportamiento externo:

Por ejemplo, un filtro tiene como funcin filtrar y est compuesto porresistencias, capacidades, ... Podemos decir su funcin sin decir de lo que est hecho.

Un Sistema nos servir para abordar la complejidad, es decir, describe orepresenta algo complejo. Habr que ver esa complejidad y decidir qu partescomponen el Sistema: divisin. Nos servir el concepto de Sistema para describir algoque ya existe: anlisis y sntesis. El anlisis describe la realidad compleja de arribaabajo; 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:


Hay divisiones ms tiles que otras. Por ejemplo, las que hacen que el nmerode elementos sean pequeos, sus interacciones dbiles. As que, el concepto de Sistemanos 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 dedesarrollo de Sistemas o arquitectura de Sistemas o diseo de Sistemas.

La ingeniera es el arte de disear y optimizar Sistemas partiendo de unanecesidad y terminando con una especificacin de cada uno de sus elementos (lo quetiene 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 unanecesidad a un Sistema:

El proyecto es una particularizacin de esa actividad de desarrollo, es un casoparticular.

El proceso de desarrollo es algo complejo, por lo que se le aplica el concepto deSistema: se dividir ese proyecto (con una funcin global), ese Sistema. Esta divisin sepuede hacer de muchas formas, veremos la ms sencilla, pero con muchosinconvenientes.


El modelo ser secuencial:

Cada proceso utiliza como entrada la salida del anterior e independizamos cadatrozo. Para que sea fcil, se pone pocos trozos pero bien definidos y relacionados con elde 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 alos requisitos.

- anlisis identificar un Sistema que cumple con esos requisitos. Pasamos de losrequisitos a las especificaciones del Sistema (suelen ser de alto nivel).

- diseo divisiones sucesivas de elementos hasta elementos manejables. Pasamosde las especificaciones del Sistema a especificaciones de elementos.

- construccin construye el sistema a partir de documentos. Construir es obteneruna o varias realizaciones. Pasamos de las especificaciones al sistema real.

- verificacin comprobar que el sistema cumple las especificaciones. Casi nunca esposible 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 clientees quien conoce, concreta y define la necesidad (empresa, ...); el que tiene lainformacin.

Sus caractersticas son:


- 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 algoambiguo, 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 queharemos son:

- identificar las alternativas de tecnologa, divisin y asignacin de requisitoselementos.

- decidir tecnologa optimizar. A veces, el criterio de optimizacin vendr dado.- especificar: (es como optimizaremos)

Sistema conjunto de elementos y conjunto de especificaciones. Unnivel 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 unapersona) y sus especificaciones. Al final, tenemos un conjunto de especificaciones deelementos: cmo realizar un elemento que haga algo. Tambin, se suele hacer ladocumentacin 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 alproceso.

CONSTRUCCIN.

Las actividades que se realizarn son :

- diseo (no complejo).- compras.- fabricar.- pruebas cada elemento por separado.


- integracin los elementos fabricados y comprobados; se juntan y prueban loselementos de mayor nivel hasta el sistema, que no se prueba.

Se dice que estas actividades no son de ingeniera de sistemas. Hay pocaactividad de diseo, de toma de decisin. Son actividades con poca incertidumbre,fcilmente planificable.

VERIFICACIN.

Se suele decir que cumpla los requisitos, normalmente. La verificacin requierede herramientas de prueba (otros sistemas que se enfrentan al sistema a verificar). Lossistemas complejos tendr verificaciones complejas e incompletas. A veces hay quedisear 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 laexplotacin.

Explotacin del Sistema.

Las actividades que se hacen son:

- fabricacin hace realizaciones (sistemas).- instalacin actividad que hay que hacer con un sistema fabricado

(particularizacin).

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

- mantenimiento es la funcin que permite mantener el ofrecimiento del servicio.Hace falta, ya que los sistemas con el tiempo se degradan. Hay un mantenimientoasociado al sistema (conocido) y otro al Sistema. Este ltimo es quizs msimportante, ya que mantiene el Sistema al da.

- soporte es lo dems que hace falta: entradas, llevarle combustible, ...


Se suele llamar ciclo de vida del Sistema al tiempo que va desde la necesidadhasta que se desecha (fin de la explotacin):

Hay dos desechos: del Sistema y de los sistemas (realizaciones). Los ciclos devida del Sistema pueden variar mucho: largo ciclo de vida del proyecto y corto deexplotacin o, como es general, el ciclo de vida del proyecto ms corto que laexplotacin (infraestructura civil).

Clasificacin de proyectos.

Lo podemos clasificar segn el tipo de usuario; el usuario es el beneficiario delservicio. Habr dos tipos de proyectos:

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

- fabricacin masiva se hacen muchas realizaciones. Los usuarios son desconocidosy eso puede ser un problema; por eso es importante que el Cliente sea capaz de definirla necesidad, por eso ser el marketing quien defina la necesidad y haga de promotor.

a medida fabricacin masivausuario conocido desconocidos

promotor usuario Marketingnmero de realizaciones pocas(*) (una) muchas

Cliente usuario Marketing

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


Tema 2: Sistemas complejos y su realizacin.

- Sistema.- Estructura.- Interfaces.

Sistema.

Es un concepto mediante el cul describimos un artefacto compuesto por cosasms pequeas que, relacionadas entre s, cooperan y satisfacen una necesidad. La ideaes: divide y vencers. Habr que hacer dos procesos mentales para usar el concepto deSistema 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. Paradescribirlo usaremos menos elementos. Decimos su funcin con una palabra (sies posible): medida de tensin alterna. Detallando ms, se puede decir que mideel valor eficaz de una tensin alterna y lo presenta visualmente. Si se sale de loslmites, 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 trminostecnolgicos sino funcionales. Las interacciones son sencillas: representacionesdel interfaz a medir.


Se pueden hacer otras descripciones de las interacciones, viendo lasinteracciones externas que hay (aparte de las de entrada y salida) y de lasinternas. 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.


La divisin no es nica, por lo que hay que buscar la ms adecuada. Lo generales usar niveles jerrquicos de descripcin y usar la abstraccin.

El objetivo es describir algo complejo. Segn esto, nos interesa una divisin uotra, segn para qu. No debemos explicar ms cosas de las necesarias ya queconfunden.


En general, vamos a tener que usar niveles de complejidad. Puede ser unelemento 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 elSistema. Si usamos muchos niveles jerrquicos, al bajar los elementos sern mssencillos. La gracia ser que aunque estemos en alto nivel, aunque sea complejo, nodebe ser compleja su descripcin. Esto es, no por subir de nivel, la descripcin de lafuncin ha de ser ms complicada.

El uso de la abstraccin es fundamental para hacer todo esto. La abstraccin esun proceso mental por el cul filtramos los detalles y nos quedamos con la parte de ladescripcin que nos interesa (elegimos las palabras representativas de la funcin).

Adems, la abstraccin permite representar Sistemas distintos pero quecomparten 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 verotras cosas para entender el Sistema a ese nivel.

Veamos algunos ejemplos de Sistemas. Primero haremos una descripcin noabstracta 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 qued agua a la casa.

Vamos a intentar mejorar el Sistema. Los problemas que tiene es que sedesperdicia, a veces, agua y se corre riesgo de no tener agua cuando queramos. As quecompletamos el Sistema con un aljibe, como vemos en la figura (inicialmente no


estaba). Mejoramos la funcin del Sistema, ya que somos capaces de dar ms agua queel caudal de la bomba y no desperdiciamos agua. Tambin subsanamos el fallo desuministro de agua.

Una descripcin ms abstracta del ejemplo sera: el Sistema es un Sistema desuministro (es la funcin) con dos interfaces externos: demanda y suministro.

Tiene el mismo problema: alto riesgo de fallo y desperdicio de agua. Aadimosal Sistema la funcin de almacenamiento que es:

El almacn, cuando se le pide, entrega para aumentar el contenido. Cuando elcontenido llega a la mxima capacidad, se corta el suministro (flotador del aljibe). Pidesi no est lleno. El sistema global sera:

Sera un Sistema de suministro con almacenamiento; hemos mejorado el servicioal desacoplar la demanda del suministro.

La ventaja que la abstraccin tiene es que puedo emplear esta descripcin para elsuministro de agua o para lo que sea: flujo de caja, sistema de alimentacinininterrumpida, desacoplo de circuitos integrados, ajuste de velocidad en un sistema detransmisin digital,...

sistema elemento real elemento funcionalsuministro de agua aljibe almacenamiento

alimentacin ininterrumpida batera almacenamientoflujo de caja cuenta bancaria almacenamiento

desacoplo de C.I.s condensador almacenamientoajuste de velocidad (Tx) buffer de memoria almacenamiento


El elemento funcional permite hablar en un lenguaje nico (abstracto), aunquesea ms difcil.

EJEMPLO DE ABSTRACCIN 2: RED TRONCAL.

Ahora presentamos un modelo abstracto y luego particularizaremos para varioscasos.

La funcin que hace este Sistema es el transporte. El Sistema consiste en:

Los accesos estarn enlazados con terminales. En la descripcin interesar dar lafuncin 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 deenlaces capaz de transportar varios objetos simultneamente; el tronco hace la funcinde multiplexacin. Los nodos hacen la funcin de conmutacin, esto es, intercambianobjetos de un enlace a otro.

Podemos hablar de funciones del Sistema. Por ejemplo, el encaminamientoconsiste en elegir un camino de un terminal a otro a travs de la red troncal; habr quedecidir qu troncos se utilizan y cmo hacer la conmutacin a los nodos.

Concretando, puede servir para: sistema de telefona de rea extensa, transportede agua, electricidad, gas, ferrocarril, ... Cualquier Sistema de transporte de reaextensa.

En telecomunicacin, los nombres de los elementos se mantienen; en transportede energa elctrico, a los nodos se les llama contadores, ...

Volviendo a la abstraccin, hay propiedades del Sistema como la capacidad, queest asociada a las prestaciones del servicio que ofrece. Tambin se habla de lacapacidad 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 primeradescripcin que hago es la de usuario. Su funcin :

es ejecutar automticamente algoritmos. poder cambiar fcilmente el algoritmo.


De momento slo nos interesa lo que hace; al usuario hay que decirle cmofunciona los interfaces, sin necesidad de que sepa lo que hay dentro:

algoritmo se le muestra como una secuencia de instruccin (es unaoperacin elemental). Necesitan un cdigo (representacin deoperaciones elementales).

Esto es una representacin para el usuario. Ahora bajamos un poco ms. Lasolucin en cuanto divisin en parte es:

Cada nombre nos dice lo que hace. Los elementos estn relacionados con lasinteracciones que vemos. La idea original se sigue usando, aunque conmodificaciones. El gran invento es que en la memoria se almacenan los datos deentrada 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 dela funcin con un nombre y luego con unas cuantas lneas. Es importante el manejode lenguaje abstracto, en funcin de hacia quien vaya dirigido. Este ejemplo es muycomplejo, 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.


Concepto de estructura.

La estructura es la distribucin y orden de las partes de un todo. Para nuestrolenguaje, al todo le llamaremos Sistema y a las partes, elementos.

La estructura tambin nos dice con quin se relacionan los elementos. Endefinitiva: el orden. Adems, hacen falta las funciones de los elementos. Peroestrictamente, la estructura equivale al orden (sin funciones ni interacciones).

Para representarla, se puede usar matrices de adyacencia, o definirlo como unconjunto de elementos (A = {a i}). La forma ms habitual de representar la estructura esmediante grafos (orientados).

El orden (estructura) determina la funcin global del Sistema.

Algunos ejemplos son:

- ismeros de qumica inorgnica mismos elementos pero cambiando el orden enque 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, podemoshacer 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 interaccinen 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 deinteracciones a la vez.

Hemos hablado antes de fiabilidad: un elemento falla cuando no cumple sufuncin. Todos los elementos llegan a fallar en algn momento, debido a ladegradacin. En este estado de fallo de un elemento, no tiene porqu fallar todo elSistema.



Vemos el diagrama lgico de fallos.

El estado de fallo se representa por un interruptor. Si un elemento falla, en esteejemplo, no se cumple la funcin global. Por tanto, los fallos tambin hay queconsiderarlos en las estructuras.

Vistas.

Son representaciones parciales del Sistema. Recordemos que cadarepresentacin tena los mismos elementos en distintos grupos. Las vistas tienendistintos 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 delSistema 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 unadivisin en partes exclusivamente funcional. Los elementos hacen funcionesdistintas 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 susfunciones y sus relaciones. Esto sirve para:

- organizacin eficiente del trabajo.- asegurar el cumplimiento de la funcionalidad.- facilitar el mantenimiento del Sistema.


c) vista real no es del Sistema global, sino de elementos relacionados. No es del todofuncional puede haber repeticin de funciones y agregacin.

La agregacin se refiere a que en la vista funcional se separaban en las partesque 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 funcionesiguales para alcanzar ms prestaciones.

- escalabilidad poder tener Sistemas con distintas prestaciones ydistintos 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, unofrecimiento de objetivos pero cuantificado, por objetivo de fiabilidad, econmico.

d) vista de producto el Sistema es considerado como un conjunto de elementosfsicos a ensamblar; el objetivo es la construccin. La funcionalidad no importademasiado, 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 hayotras posibilidades.

fotocopia 33.3 vuelta abajo.

No es una vista funcional, es la vista real. Hay propiedades del Sistemaque 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 leinteresa la vista funcional (esta vista la vemos abajo).

La vista funcional servir en el diseo: funcin del conmutador (C) yfuncin de multiplexacin (T). Hay funciones comunes, como la alimentacin.


El diseador podr hacer su trabajo. Lo importante es no tener en cuenta todaslas vistas a la vez.

Estructura modulares configurables.

MDULO pieza o conjunto de piezas que se repite en una construccin para hacerlams fcil, regular o econmica.

SISTEMA MODULAR el que usa mdulos. Consigue funciones o prestaciones porrepeticin de elementos iguales. Por ejemplo: ladrillos, construccin que es distintode ensamblaje.

SISTEMA CONFIGURABLE el que admite distintas estructuras con los mismos elementospermitiendo 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 distintasconfiguraciones; los elementos pueden estar o no estar.

- re configurables Sistema que admite diferentes estructuras (diferentesfunciones), que puede cambiar de una a otra sin dejar de prestar servicios. Se dice queel Sistema puede estar en distintos estados. Por cambiar de estructura, no tiene porqucambiar 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 baratoy fcil, siendo un sistema a medida.

fotocopia 33.3 vuelta arriba.


La particularizacin disea la vista real adaptada a una necesidad concreta. Laparticularizacin 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 transferenciade la energa:

Vemos que cambian automticamente el sentido de distribucin de la energael sistema es reconfigurable cambia su estructura de transferencia de energa.


Interfaces.

Concepto de interfaces.

Es una representacin de la interaccin entre dos elementos, que normalmenteconsiste en el intercambio de algo material.

EXTREMO DEL INTERFAZ elementos que interaccionan. Si tienen la mismafuncionalidad 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 losinterfaces, mientras que los diseadores se encargan de los elementos.

Es ms importante definir los interfaces detalladamente que asignar funcionespara crear elementos. Es muy importante disear los interfaces con mucho nivel dedetalle!! 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.


- transferencia energa elctrica a travs de la toma de corriente.- transferencia de calor ventilador trasero.

ACOPLOS interacciones no deseadas. Hasta ahora hemos hablado de interaccionesdeseadas. Una interaccin no deseada es, por ejemplo, la diafona en los sistemas detelefona.

El interfaz es un filtro selectivo. Transfiere lo que queramos y no deja pasar loque no queramos. En realidad, lo que hace es atenuar las interacciones no deseadas, nolas puede eliminar completamente. Hay que evitar la transferencia de fallos, noatenuarlas.

La capacidad de diseo de un interfaz.

El interfaz puede ser:

- entre dos elementos fijos es el caso ms sencillo. Si nos equivocamos no esdemasiado grave el Sistema puede an funcionar. Adems, es fcil volver atrs.

- entre dos elementos intercambiables tenemos elementos distintos que se quierecomunicar. Un ejemplo es el interfaz RS-232 (cable de impresora). Es un interfaz mscomplejo:

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

EJEMPLO: RS-232.

Su origen era para la comunicacin de ordenadores a travs de la red telefnicapblica.

El interfaz RS-232 tiene las siguientes partes:


funcionalelctrica dinmicaelctrica estticamecnica 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 unasituacin 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 altransmisor y al receptor. Cuanto ms pequeas sean las tolerancias, ms difcil esdisear los extremos.

El interfaz RS-232 es muy tolerante. Un problema de tener tolerancia grandees la verificacin hay ms combinaciones posibles. Adems, en general, un interfazms tolerante es menos eficiente.REGLA no seas intolerante si no es necesario.

- filtrado / aislamiento un interfaz deja pasar las transferencias deseadas, secomporta como un filtro: atenuar o aislar las transferencias no deseadas. Se consiguea costa de reducir mucho las prestaciones. Por ejemplo, RS-232 hilos paralelosdiafonas. Cmo se evita? Disminuyendo la velocidad del terminal. Habr uncompromiso entre atenuacin prestaciones.

- proteccin la interaccin indeseada puede producir daos en el otro extremo, esparecido a lo anterior. Se busca que el interfaz produzca una aislamiento que, aunquefuncione 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 perosin que le afecte el fallo (los elementos redundantes suelen estar unidos).

- extensibilidad un interfaz es extensible si permite aumentar su funcionalidad oprestaciones (capacidad de transmisin) ms all de lo inicialmente permitido. Conun coste muy pequeo. El interfaz es capaz de tener mayor prestaciones yfuncionabilidad. Por ejemplo, direccionamiento (mala extensibilidad si es cara).

Veamos el ejemplo; problemas de direccionamiento: 24 procesadores, bus de 5hilos (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 alser el coste tan pequeo. Los interfaces se disean al principio y son difcilescambiarlos despus, en telecomunicacin. Tampoco es fcil preverlo, debido a que latecnologa crece exponencialmente (ejemplo, PC).


Tema 3: Caractersticas de los Sistemas.

- Proceso de explotacin.- Caractersticas generales.- 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 secomunican 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 paraampliacin de servicios o errores del sistema detectados durante el ciclo de vida.

(2).- Informacin de fallos.


(3).- Informacin de operacin: estado, alarmas.(4).- Orden de operacin.(5).- Informacin de problemas de mantenimiento.(6).- Equipos, repuestos, transporte. Talleres.(7).- Documentacin, formacin y gestin.(8).- Documentacin, formacin y gestin.(9).- Informacin de problemas de operacin.(10).- Equipos, repuestos y reparaciones.(11).- Actualizacin de configuracin si hay que cambiar los sistemas instalados.(12).- Informacin de problemas (peticin de cambio).(13).- Actualizacin de configuracin.(14).- Informacin de problemas (peticin de cambio) de fabricacin.

La ingeniera de Sistemas redisea el Sistema a partir de nuevas necesidades delcliente. 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 operacinno les parece normales) como peticiones de cambio. Vemos un resumen de esto en lafotocopia 52.11.

La configuracin es el conjunto de documentos del Sistema.

Un problema tpico de telecomunicacin es que estas funciones tienecaractersticas de rea extensa; es decir, todas esas funciones estn distribuidas en reasmuy extensas y se complica el problema. Por ejemplo, la red de telefona. Es la red deacceso de telefona mvil (mantenimiento, operacin y soporte), cajeros de banca, redde telecontrol. Se suelen montar con redes jerrquicas, as algunas funciones se hacen adistancia (las ms complejas) y las ms sencillas cerca (sustitucin de un elemento).

Caractersticas generales.

Nos dicen lo bueno que es el servicio. Son las que vienen en las hojas decaractersticas:

- funcionalidad descripcin detallada del servicio que ofrece el Sistema, sincuantificarla.

- prestaciones cuantifica el servicio (pueden estar relacionadas con variosinterfaces).

- interfaces exteriores interacciones del Sistema con sistemas exteriores.

En el diseo hay que plantearse la funcionalidad y las prestaciones encondiciones normales (nominales). Se considera tres posibles estados de lascondiciones:

1 M.Op. Manuales de Operacin.


- 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 influyanegativamente 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 lascaractersticas slo hay que tener en cuenta lo nominal.

Respecto al interfaz externo, un sistema es conforme a tal interfaz. Laconformidad quiere decir que el sistema cumple las especificaciones de ese interfaz. Lainteroperatividad es algo ms general; no se refiere a un interfaz, se refiere al sistema: elsistema 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 lossentidos 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.


Esta facilidad y eficacia de Operacin y de aprendizaje dependen decmo 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 deoperacin.

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 seaconfigurable y escalable, es decir, construir distintas realizaciones del Sistema quetengan, o bien, un subconjunto de la funcionalidad completa o bien prestacionesreducidas; a cambio de un coste (de la realizacin y de la explotacin), tamao.

La escalabilidad se refiere a las prestaciones. Las estructuras modulares tienenuna buena escalabilidad y configurabilidad.

- fabricabilidad es la facilidad de fabricacin. La fabricacin es la construccin demltiples realizaciones del Sistema. Las estructuras modulares ayudan en lafabricabilidad. Veamos el proceso de fabricacin cuando usamos una estructuramodular:

Las pruebas suelen ser ms o menos restrictivas, se suelen intercalar pruebaspara evitar la propagacin de errores: difcil determinar y / o sustituir. A veces estostambin estn separados fsicamente.

Los mdulos suelen tener funcionalidades concretas. Las entradas a esteproceso 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 yposibles combinaciones de configuracin de equipo.


especificaciones de ensamblaje de equipo y de mdulo (o demontaje) qu piezas encajan, se unen, localizacin decomponentes. Las de equipo son ms complicadas, pues puedehaber distintas configuraciones.

especificaciones de prueba lo hace la ingeniera de Sistemas,quien disea el Sistema tiene que hacer todo esto (menos lospedidos). Cul ser el alcance de las pruebas?

Veamos de qu depende la fabricabilidad, los factores que le afectan (hay quetenerlo 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). Debeexistir la posibilidad de hacer ensamblaje automtico. Reducir el nmerode mdulos distintos (inversamente proporcional a la configurabilidad) ynmero de partes (adquisicin ms fcil). Respecto al nmero demdulos, se puede buscar un exceso de funcionabilidad mdulos que asu 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 elnmero de mdulos y partes es bueno, tambin, para el punto de vista de diseo y dela mantenibilidad, a parte de la fabricabilidad.

EJEMPLO: SISTEMA DE TRANSMISIN MODULAR CONFIGURABLE, PENSADO PARA HACERUNA FABRICACIN FLEXIBLE (PDH).

Veamos una realizacin:

Veamos cul es la estructura funcional:

fotocopia 52.2


Esto es una solucin para los operadores de comunicacin y / oempresas, tambin es escalable. Vemos en la fotocopia de arriba la estructura delSistema que usa la jerarqua plesiocrana, segn la ITU. Vemos que hay cuatrointerfaces entre dos multiplexadores.

Vemos todas las posibles configuraciones que hay. Tambin haymdulos de alimentacin; su nmero depender del nmero total de mdulosque haya. Hay un conmutador para poder tener el enlace conmutado. Laestructura fsica significa que empaquetamos toda esta funcionalidad.


Todas las funciones que se nos ocurra deben caber en el mismo espaciofsico (modularidad fsica). Las complejidades iguales en tamaos iguales.


Las unidades antes se montan en armazones (tambin las unidades dealimentacin). La placa madre se usa para interfaces exteriores como lasexteriores.

La vista (estructura) de producto nos dice qu combinaciones sonposibles.


Tambin salen los armazones, los que caben en cada uno. Cada uno delos armazones tiene alimentacin doble.

Normalmente, esto es un equipo de transmisin, distinto al resto; puescada usuario tiene necesidades distintas problema de fabricacin, ya que losmdulos son muy caros y por ello se hace a medida, tanto la configuracin comoel mdulo. Requiere una tcnica de fabricacin complicada: pedido mduloque se requiere y se fabrica.

Hemos visto, tambin, la escalabilidad y coste proporcionado al nmero decanales. Hay una configuracin mnima.

- evolucionabilidad- es la facilidad de extender el ciclo de vida del Sistemaadaptndolo. 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:


estructuracin estructura de alto nivel del Sistema, funcionalmentecomo 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 sondifciles de cambios.

documentacin hay sistemas que duran muchos aos. Para hacercambios en un Sistema es conveniente documentar el porqu se hacen lascosas 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 unperiodo de tiempo dado y bajo unas determinadas condiciones.

En esta simplificacin suponemos que un Sistema puede estar en dos estados: enservicio 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 lossistemas 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 binariadependiente del tiempo, una funcin probabilstica.

Las condiciones influyen en la fiabilidad, puede ser la temperatura o el trabajoque est haciendo (esfuerzo).

Medidas.

El sistema podr estar en dos estados, lo representamos:


Se define ciertas funciones:

- funcin de fiabilidad, R(t) es la probabilidad de no haber fallado pasado untiempo t desde que el sistema entr en servicio. Tambin se llama: funcin desupervivencia. La experiencia nos dice que la funcin de fiabilidad es una funcinmontonamente 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 montonamentecreciente.

- funcin de densidad de fallo, f(t) tambin es decreciente. Cuanto ms tiempopasa, ms probabilidad de fallo.


- MTTF (Tiempo medio hasta el fallo) es una media. Es muy usado, pues es unnmero, pero no nos da el comportamiento.

=

0

)( dttftMTTF

- Funcin tasa de fallos, z(t) es parecida a la densidad de fallos. Es la probabilidadcondicionada (condicional) a que el sistema no haya fallado ya.

( ))()()(

)()(

''int,)(

tRtftz

tRdttf

tervalonofalloendtttfalloenprdttz ==

+=

La tasa de fallo ya no est claro que sea decreciente, de hecho puede sercreciente. 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 usanexpresiones matemticas:

- exponencial.- Weibull.

MODELO EXPONENCIAL.

Slo tenemos un parmetro , suponiendo: tetR =)( ; tetf = )( ; =)(tz ;

1

=MTTF .

Este modelo implica que la tasa de fallos es constante, es decir, que el sistema noenvejece. 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 quesignifican.


MODELO DE WEIBULL.

Es tambin una funcin exponencial, pero ms complicada: tetR =)( . Para

=1, tenemos (el modelo exponencial) la tasa de fallos constante: 1)( = ttz .

- > 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 fallosvariante en el tiempo.

Estos dos modelos tienen parmetros. Veamos de qu dependen los parmetrosde 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 sermucho ms larga que el tiempo de tasa de fallo creciente y decreciente. Solemos usar ladivisin en tres zonas, como vemos en el dibujo.

La primera zona se debe a problemas de proceso. Los que superan el primerinstante (mortalidad infantil de los dispositivos electrnicos) ya tienen la tasa de fallosconstante. Al final tienden a envejecer.

Normalmente, los componentes electrnicos se usan durante el tiempo de tasa defallos constante; pasado ese tiempo (que es conocido por la experiencia), se tira. Antesde usar los componentes electrnicos, se ponen en funcionamiento, para que se mueranlos que tengan fallos de fabricacin: quemar el equipo. Ese quemado sirve para


asegurar que el sistema se encuentra en la zona de tasa de fallos constante, antes dedrselo al usuario. En esta zona podemos predecir la fiabilidad, pues conocemos la tasade fallos del componente.

Los componentes pueden ser ms o menos fiables, dependiendo de si es mayoro menor. Los dispositivos mecnicos se comportan:

Fiabilidad y esfuerzo.

La fiabilidad depende de las condiciones en la que el sistema funcione. Se defineunas condiciones normales. Si el sistema no est en condiciones normales, se dice queel sistema est sometido a esfuerzo. El esfuerzo se mide en funcin de magnitudes quemiden esas condiciones normales:

permitidomximovaloraplicadovaloresfuerzo

___

=

El esfuerzo unidad es el mximo en que un sistema funciona.

Un sistema en condiciones normales tiene mejor fiabilidad que cuando estsometido 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 esfuerzosintencionalmente. Ejemplo: funcionamiento para la mortalidad infantil para

2 fiabilidad probabilidad de que el sistema ofrezca el servicio.


condiciones esforzadas, acotando este tiempo (dentro del margen permitido). Otroejemplo sera medir hasta el tiempo medio de fallo del sistema, que a veces es deaos, por esos se usa en condiciones forzadas. A veces, es til el esfuerzo.

- las condiciones normales deben estar lejos de las condiciones mximas para elrendimiento mximo siendo ms fiable (menor esfuerzo). Para que el sistema seafiable, sobredimensionamos las cosas (ojo, que tambin cuesta dinero).

Un sistema funciona igual en condiciones normales que en sobrecarga, pero laprobabilidad de fallo aumenta conforme aumenta el esfuerzo.

Fiabilidad y estructura.

La estructura de fiabilidad es una representacin del comportamiento delSistema 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 sistemacon la fiabilidad de cada uno de los elementos (siendo stos independientes entre s).

Conocidas las funciones de supervivencia de cada elemento, podemos conocer lafuncin de supervivencia del Sistema global (depende de sus elementos) (N es elnmero de los elementos):

)()(1

tRtR iN

i==

Se suele suponer el modelo exponencial, es decir, los elementos tiene la tasa defallos constante:

tN

iii

N

i

N

ietttRtR

=

==

==== )exp()exp()()(111

El sistema completo tambin tiene la tasa de fallos constante. Funciona con elmodelo exponencial, donde la tasa de fallos es la suma de las tasas de cada uno de suselementos. Tambin es fcil calcular:

=

=

===N

ii

N

ii MTTFMTTFMTTF

1

111

1

1 )(


Vemos que el elemento que tiene menos tiempo medio hasta el fallo es el quedomina. 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 Sistemasigue haciendo lo mismo, con el mismo comportamiento exterior y la misma funcin.

La redundancia simple consiste en repetir un elemento (misma funcin). Haydos tipos de redundancia:

redundancia activo reserva de los elementos repetidos, slo uno cumple con sufuncin y los otros estn inactivos.

redundancia en reparto de carga la carga total del trabajo a hacer se reparte entrelos 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 seruna cierta medida de la redundancia, donde N es el nmero de elementos necesariospara realizar la funcin (prestaciones requeridas). As si M es mayor que N s que hayredundancia; por ejemplo si M = N + m, m ser el nmero de elementos nonecesarios 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 seguiradando servicio. El Sistema falla slo si todos los elementos fallan, por eso tambinrecibe el nombre de estructura en paralelo. Se pueden representar con una funcinAND.

))(1(1)( tRtR i=


Se puede resolver este caso si la tasa de fallos de todos los elementos soniguales:

i iguales =

=

=

N

i iMTTF

1

11

Mejoramos un poco para el tiempo medio hasta el fallo; es ms, si crece i laganancia marginal es cada vez peor.

Con reparto de carga, la fiabilidad de cada uno de los elementos es mejor puesmenor 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, siendoesta 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 tendrdesgaste (la tasa de fallos no crece).

La realidad es ms complicada. La forma de aumentar la fiabilidad con mselementos es si podemos recuperar los elementos. Hemos calculado el tiempo de fallosde todos los elementos, pero las estructuras redundantes son ms tiles si los elementosson 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:


sin mantenimiento: 5,1

1 =

MTTF

con mantenimiento: MTMTTF 221

Lo normal es que se utilice redundancia simple con mantenimiento, pudiendohacer que el tiempo medio hasta el fallo sea muy alto, ya que podemos hacer que eltiempo medio de recuperacin (TM) sea chico. Pero no siempre se puede hacermantenimiento, por ejemplo en el satlite. En telecomunicacin se puede hacermantenimiento, mejorando mucho el tiempo medio hasta el fallo.

Hemos supuesto la independencia entre fallos de los elementos, pero no es fcilconseguirlo en sistemas electrnicos. Normalmente, cuando se hacen Sistemasredundantes, a los elementos se les llaman bloque de fiabilidad, si son capaces deaislar, desde el punto de vista de transferencia, el fallo.

Hasta ahora esto era muy drstico: el Sistema falla o funciona. En los sistemascomplejos no se habla de fallos de servicio, sino de degradacin de las prestaciones y sise 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 delservicio sea aceptable, usando un nmero que expresa lo lejos que estamos del serviciototal. 0 ser el fallo total y 1 servicio completo.

En relacin de esto, se refiere a la vulnerabilidad de un Sistema al fallo de unelemento. La experiencia nos dice qu sistemas son ms vulnerables que otros y quelementos 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 deelementos tambin son vulnerables al fallo.

Los elementos, hasta ahora, tambin tenan dos estados. A veces se usan variosestados para los elementos.

Los modos de fallos consisten en que tanto el sistema como los elementos estnen varios estados: en servicio o modos de fallos. El fallo significa degradacin de lafuncionalidad. Los modos de fallos no hace falta que sean continuos. El modo de fallose define como efecto del servicio, no la causa. Por ejemplo, el modo de fallo delcondensador sera: el valor C se sale de la tolerancia, circuito abierto, cortocircuito.


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 sinremedio. Los Sistemas complejos fallan, muchas veces, y no se debe a una degradacinfsica 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 yprobando. 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, porpesimismo, 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.

3 Nos referimos a errores de diseo y de fabricacin.


Un error siempre provoca fallo? No siempre. El fallo del sistema se produce sise produce ciertas condiciones, como un estado no previsto en el diseo. El error semanifiesta en el fallo. Si el Sistema no pasa por ese estado, no se manifestar el error. Elfallo depende de las condiciones del sistema. No siempre un error produce fallo.

Al disear un Sistema no sabemos cules son los errores ni las condicionesnecesarias para que si hay errores, se produzcan fallos. No podemos hacer nadadeterminista. Haremos de esto un problema estadstico, un problema de fiabilidad.

Los errores lo tratamos como un problema ms de fiabilidad. Con este tipo defiabilidad, si un sistema entra en modo fallo es fcilmente recuperable, requiriendo unaaccin: el re arranque.

Los Sistemas software tambin fallan, buscaremos algo relacionado con lafiabilidad, factores que influyen en la fiabilidad relacionada con los fallos debido a loserrores del Sistema. Vemos de qu depende la fiabilidad de un Sistema lgico (no haydegradacin fsica):

- complejidad cuanto ms complejo sea un Sistema, ms difcil de disear mserrores.

- 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 deestados que se produce es muy alto, mayor probabilidad de caer en un estado nodiseado. Los errores son los mismos, pero la probabilidad de que los errores seconviertan 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 undeterminado nmero de errores y que la tasa de fallos es constante. Cuando falla elsistema, lo re arrancaremos, teniendo el mismo nmero de errores y la misma tasade 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 dedepuracin, diseo, experimentacin y en la explotacin. Ahora cuando se produceun fallo, investigamos: sus causas, el error que provoca el fallo y las condiciones enlas que se dan. Corregimos el fallo eliminando la probabilidad de que se produzca unerror:

o eliminar el error oo eliminar las condiciones

En la fase de explotacin, se elimina el fallo de la forma ms fcil posible. Eslo que se denomina parche; pues no se corrige la estructura, sino evitar lascondiciones de fallo.

- Modelo de introduccin de versiones en los sistemas complejos, cuando entra enla fase de explotacin, al detectar un error grave, los diseadores del sistemaproponen un parche sin cambios estructurales. Esto reduce la tasa de fallos delsistema, pero no baja de un determinado nivel.


Se introduce una nueva versin del sistema al hacer cambios estructuralescuando hay muchos parches, corrigiendo los errores a ms bajo nivel. Pero las nuevasversiones tiene una tasa de error mayor a la anterior, pues se trata de una nuevaversin.

Pero la tasa de error se baja un poco, conforme se vayan detectando loserrores. En los nuevas versiones, a parte de la correccin de errores, se le aadennuevas 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 sistemasson 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 elmismo concepto.


Pero existe otro tipo de mantenimiento, que consiste en evitar que el sistemafalle (sobretodo para sistemas con desgastes). Tiene como objetivo aumentar lafiabilidad.

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 laactividad del mantenimiento de un sistema.

Veamos una definicin de mantenibilidad: probabilidad de que un sistema (loque 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 conprocedimientos 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 responsabilidadde 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 queese 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:


El ciclo de mantenimiento correctivo tambin se llama tiempo en que el sistemaest 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 ladeteccin.

La preparacin no depende del sistema (depende de los recursos que tenga laorganizacin), sino de la organizacin del mantenimiento.

El ciclo de mantenimiento activo es lo que ya depende ms del Sistema. As, conla localizacin averiguamos qu elemento falla y qu hay que hacer para reponer elsistema.

Para recuperar un elemento hay que desmontar para poder acceder al elementoque necesito recuperar, lo recupero: reparndolo, cambindolo por otro elemento,...Despus se monta. Por ltimo hay que verificar que el elemento se ha recuperado y quehemos ensamblado bien el sistema.

Durante el bloque de desensamble, recuperacin, ensamble y verificacin elsistema 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 origende una accin de mantenimiento preventivo no es un fallo. Hay dos eventos quedesencadenan una accin de mantenimiento preventivo (origen):

- supervisin vemos que hay algo que podra producir un fallo, generalmente pordegradacin 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. Otroejemplo sera el aceite del coche.

Se usa con sistemas con tasas de fallos crecientes: sistema con desgaste osistemas con tiempo de vida limitado.

Cuando la tasa de fallos es constante no tiene sentido el mantenimientopreventivo, pero a veces se hace. Ejemplos: reajustes con potencimetros, calibracionesperidicas.


Medida.

- medida de frecuencia frecuencia a la que se requiere las acciones demantenimiento. Se usa el tiempo medio entre mantenimiento (MTBM). En sistemasde tasa de fallos de constante, el tiempo medio entre mantenimiento es igual al tiempomedio hasta el fallo del conjunto de los elementos. En el sistema con mantenimientopreventivo, el tiempo medio entre mantenimiento estar relacionado con el tiempo devida til del elemento con desgaste.

- medida de tiempo tiempo que dura la accin de mantenimiento. La medida es eltiempo de recuperacin (TTR, Time To Restore). En caso de mantenimientocorrectivo, el tiempo de recuperacin incluye todo el ciclo y hay cosas que nodepende del diseo. Tambin llamado tiempo de cada del sistema. El tiempo derecuperacin depende de lo que hayamos trabajado en el diseo y en la organizacinde 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 verdades 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 eltiempo s que repercute al servicio. El coste afecta al que haga el mantenimiento.

Disponibilidad.

Es otro concepto diferente a mantenibilidad. Se habla de disponibilidad ensistemas recuperables, es decir, en que una vez que falla el sistema se puede poner en elestado anterior al fallo. La disponibilidad es la probabilidad de que el sistema est enSERVICIO.

La disponibilidad (A) es la relacin que existe entre el tiempo que est enservicio y el total:


1+

=

MTTRMTBFMTBFA

Valores tpico de la disponibilidad es del 99%, 999%, 99999%; hay una altadisponibilidad de cincos nueves de disponibilidad. La disponibilidad nos dice el tiempotil en que el sistema est ofreciendo el servicio.

Para un sistema aparece la fiabilidad (MTBF), la mantenibilidad (MTTR) y ladisponibilidad (A), aunque las tres estn relacionadas. Desde el punto de vista delservicio, las tres cosas son importante. No interesa una alta disponibilidad y un elevadotiempo medio entre fallos si tambin tenemos un alto tiempo medio de reparacin,habra que limitarlo. Tampoco interesa tener bajo tiempo medio entre fallos, por muybajo que sea el tiempo medio de reparacin.

)11( =A

MTBFMTTR

Podemos dibujar la siguiente grfica.

A un sistema le pedimos una disponibilidad mnima, un tiempo medio entre fallomnimo y un tiempo medio de recuperacin mximo.

Mantenimiento automtico.

Para un sistema con alta disponibilidad, la deteccin y preparacin no se puedeadmitir.

Muchos sistemas complejos tienen funciones automticas, es decir, no requierende interaccin humana. Las funciones se automatizan para conseguir:

velocidad de respuesta. seguridad.


coste.

En el mantenimiento, se automatizan debido a sus requisitos (por ejemplo, lavelocidad de respuesta) de:

fiabilidad se necesita que el recambio sea rpido (o el rearranque del sistema, si essoftware), 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 (defunciones).

fotocopia 51.1.

fotocopia 51.1 abajo.

La supervisin siempre hace falta, ya que es una funcin de detectar losfallos. La supervisin es a distintos niveles: ms fsicos o de ms alto nivel. Elobjetivo de este sistema es detectar los fallos.

El diagnstico decide si se puede recuperar el estado sin necesidad deintervencin del operario informa a la recuperacin o a la operacin. Esteesquema suele ser de sistemas de telecomunicacin.

MANTENIMIENTO ADAPTATIVO.

Relacionado con la evolucionabilidad del Sistema. Ahora este mantenimientose refiere al Sistema. Recibe varios nombres: mantenimiento adaptativo o evolutivo odel 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.


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 humanoque permite, desde una necesidad, obtener un Sistema que resuelve esta necesidad.

Los procesos de ingeniera de modelos simples son independientes: los procesosde ingeniera se realizan de manera secuencial, y de forma paralela se realizan losprocesos de control del Diseo. Para los modelos ms complejos, se solapan.

El anlisis de los procesos de ingeniera busca la mejor solucin que cumpla esaespecificacin 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 dedefinir la necesidad. El ingeniero es capaz de disear el Sistema que cumpla lanecesidad.

ALCANCE Hasta dnde llega esta definicin? Vemos:

definir el SERVICIO (no el SISTEMA) no hay que indicar posiblessoluciones del Sistema. Hay que abstraerse a la necesidad. Por ejemplo:

El proyecto: instalar una nueva central telefnica en un barrio. Lanecesidad: el servicio telefnico a un nmero de usuario. El proyecto: instalar un radioenlace. La necesidad: ofrecer unSistema para transmitir datos. El proyecto: construccin de un puente. La necesidad: darservicio de trfico entre las orillas.

definicin no ambigua si los requisitos son cuantificables, hay que ponerel nmero. No escribir mucho sin decir nada. Por ejemplo:

reducir el impacto ambiental ? bajo coste cunto? agradable a la vista ?


definicin completa no debe dejarse aspectos importantes sin definir.Suponer cosas y el sentido comn no es admisible, no se puede suponer quelas cosas son evidentes. Lo que queremos, hay que definirlo. Dar unadefinicin formal y completa. Por ejemplo, si queremos una ampliacin deuna red de telecomunicacin: el objetivo es disminuir a la mitad de tiempo deconexin (alta) de un nuevo usuario que lo solicite en la ciudad de Mlaga deaqu a un ao, con inversiones menor que X euros.

definicin realizable tiene que haber una solucin, al menos. Si damos unadefinicin sin solucin, los ingenieros de anlisis tardarn mucho tiempo endarse cuenta de que no existe una solucin. Pero lo ms probable es que en lafase de anlisis, se deseche los requisitos menos importantes hasta que hayasolucin. Esto se sale del modelo y no debe ocurrir. Cmo se sabe si existesolucin? Por experiencia o por estudios de viabilidad, para evitar esteproblema pero que no aparecen en la especificacin de los requisitos. Otrosmodelos son los iterativos: los procesos de definicin de anlisis y diseo noson independientes y s son iterativos, para ir afinando una definicin viable.

Para que una definicin sea realizable, hay que evitar pedirlo todo (pararde pedir cosas). La dificultad est en poner slo los requisitos que sonnecesarios.

ESTRUCTURA DE LA ESPECIFICACIN DE REQUISITO (BLANCHARD) se ponen en ordenpara 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.

fotocopia 51.2 abajo.

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.


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 siesos 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 dicecmo se tiene que hacer.

Siempre hay un proceso de optimizacin, ya que habr varias posiblessoluciones. En esta fase de anlisis hay que pensar en todo el conjunto completo derequisitos (en esto se diferencia esta fase de la siguiente).

El resultado es la especificacin de Sistema, que es todo lo que tiene que ir eneste documento (contenido de toda la informacin para poder seguir los procesos):

lo que tiene que estar definido

cmo es el SISTEMA(descripcin de alto nivel)

EstructuraInterfacesFuncionesTecnologa

cmo se va a desarrollarcmo se va a probar

cmo se va a explotarUsar y Mantener


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 fasessecuenciales:

En la primera fase, se busca una solucin global al Sistema y se toma decisionesde la principal tecnologa a utilizar (ser determinante). No nos preocupa demasiadodividir el Sistema en trozos, al menos no por el problema de complejidad sino por unamejor comprensin. Se toman grandes decisiones, pues afectan al desarrollo.

En la siguiente fase, la estructuracin, s nos preocupa el hecho de que lasolucin 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 unaestructuracin: funcional, fsica, ... Tambin se considera las estructuras redundantes.

Una vez obtenidas las distintas partes, hay que asignarlas los requisitos delSistema 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.


Qu se decide?

EJEMPLO 1: decidir entre desarrollar o comprar (generalmente se refiere a partes delSistema o al Sistema completo).

Los requisitos que nos piden se pueden cumplir con un Sistema ya existente omodificndolo un poco o desarrollando un Sistema nuevo.

Partir de un Sistema tiene un coste de desarrollo menor. Tambin est el riesgode 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 tambinson criterio), tambin influye en el criterio.

herramientas de desarrollo que permiten desarrollar la tecnologa influye en eltiempo 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 puededegenerar en graves problemas en el desarrollo. Para las decisiones importantes habrque seguir este procedimiento de anlisis (de toma de decisin o anlisis de solucionescandidatas).

El esfuerzo que se le dedique a este procedimiento depender de la importanciade la decisin que hay que tomar.

fotocopia 51.3 izquierda.

En el criterio de evaluacin, los parmetros de eficacia pueden sercuantitativos o un conjuntos de parmetros tiles.

La eficacia es difcil de cuantificar o la funcionalidad. Vemos lo que puedesignificar el coste y la eficacia en la fotocopia 51.3 derecha. La ventaja de los costeses que se pueden cuantificar, la eficacia es ms difcil de cuantificar.

Lo ms fcil es minimizar el coste, pero qu coste: el desarrollo? laimplementacin? 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.


criterio 2: te

eficaciacos

obliga a cuantificar parmetros. Hay que ponderar

los parmetros de la eficacia.

Para las alternativas hay que saber bien lo que se nos pide. No hay quejuzgarlas (la decisin viene despus), slo identificarlas.

En el enfoque y tcnicas de evaluacin, a veces la decisin no la podemoshacer 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, noconocemos su valor pero s su probabilidad. Podemos calcular el riesgo, laprobabilidad de que nuestra decisin no sea adecuada. Incertidumbre es cuando nose 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 unascaractersticas 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 lasdecisiones y resultados de lo que se ha hecho. Es muy importante todo lo que noest en el documento se pierde.

Esto no se hace siempre, slo en las decisiones grandes de un proyecto se hacetodo esto. Para decisiones pequeas se saltarn algunos pasos.

Ejemplo.

Es un ejemplo real de un proyecto grande. Veremos algunas decisiones dentrodel diseo conceptual.

Se trata de una conmutador de paquetes (router) muy grande y con unasrequisitos de disponibilidad muy grande. Veremos algunos requisitos, decisiones ymodelos.

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.


escalabilidad. evolucin. gestin del Sistema.

DECISIONES:

funciones de gestin mquina hardware / software existentes tipo UNIX. (secompra)

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 centralesde red (conmutacin).

ESTRUCTURA.

fotocopia 51.4 arriba.

La capacidad est limitada por la capacidad del bus UPR. Cada bus tienecolgadas cierto nmero de unidades funcionales y si ste falla, fallan todas afectaa la fiabilidad. Si falla un enlace, slo caen las unidades conectadas a l, pero elresto siguen funcionando.

Para la alimentacin se pens en alimentacin distribuida (a cada elemento) envez de central. As mejoraba la fiabilidad.

IDST

Documents

Transcript of IDST