5.1 PARADIGMA DE ANLISIS DE LOS SISTEMAS DUROS Y BLANDOS.

Fases en el proceso de diseo de los sistemas o paradigma de sistemas El ciclo de toma de decisiones de la figura 4.1 puede dividirse en tres fases distintas y aplicarse al proceso del diseo de sistemas, como se muestra en la figura 5.1. Estas fases son como sigue: 1. Fase de diseo de polticas o preplantacin 2. Fase de evaluacin 3. Fase de accin-implantacin Fase I. Diseo de polticas o preplaneacin es la fase durante la cual: Se llega a un acuerdo de lo que es el problema. Los autores de decisiones llegan a una determinacin de sus cosmovisiones (premisas, supuestos, sistemas de valor y estilos cognoscitivos). Se llega a un acuerdo sobre los mtodos bsicos por los cuales se interpretaran las pruebas. Se llega a un acuerdo sobre que resultados (metas y objetivos) esperan los clientes (expectativas) y los planificadores (promesas). Se inicia la bsqueda y generacin de alternativas. Fase 2. La evaluacin consiste en fijar las diferentes alternativas propuestas, para determinar el grado en el cual satisfacen las metas y objetivos implantados durante la fase anterior. La evaluacin incluye: 1. Una identificacin de los resultados y consecuencias derivados de cada alternativa. 2. Un acuerdo de que los atributos y criterios elegidos con los cuales se evaluaran Ios resultados, representan verdaderamente las metas y objetivos preestablecidos a satisfacer. 3. Una eleccin de la medicin y modelos de decisin, los cuales se usaran para evaluar y comparar alternativas. 4. Un acuerdo en torno al mtodo par el cual se har la eleccin de una alternativa en particular. Fase 3. La implantacin de la accin es la fase durante la cual el diseo elegido se real iza, La implantacin incluye todos los problemas malos de: I. Optimizacin, que describe donde esta la mejor solucin. 2. Suboptimizacion, que explica par que no puede lograrse la mejor solucin. 3. Complejidad, que trata con el hecho d e que, de tener solucin, debe simplificarse la realidad, pero para ser real, las soluciones deben ser complejas . 4. Conflictos, legitimacin y control, son problemas que afectan, pero no son exclusivos de la fase de implantacin del diseo de sistemas. 5. Una auditoria o evaluacin de los resultados obtenidos del implemento de l diseo de sistemas, lo cual significa optimismo o pesimismo sobre si los objetivos pueden realmente satisfacerse y proporcionarse los resultados prometidos. 6. Reciclamiento desde el comienzo, el cual ocurre a pesar de si los resultados obtienen xito o fracaso. La tabla 9.1 (que debe estudiarse en conjunto con la tabla 2.1), compara los mtodos de la ciencia fundamentales al enfoque analtico-mecnico, como el paradigma de ciencia

aplicable al dominio de sistemas rgidos, con los mtodos de la ciencia fundamentales al enfoque de sistemas y al paradigma de sistemas, que son aplicables a los dominios de sistemas flexibles, encontrados en las ciencias sociales y otras relacionadas. Es normal esperar que las ciencias fsicas estn ms de acuerdo con las derivaciones lgicomatemticas y los procesos de razonamiento ms formales, que las ciencias sociales. Aunque Ia lgica y las matemticas tienen un papel que desempear en estas estos mtodos nunca remplazaran los procesos menos estructurados que son ms adecua dos a un dominio menos preciso. Esto es engaoso, por otro lado, para caracterizar completamente el dominio de las ciencias fsicas como exacto y el de su contraparte, las ciencias sociales, como inexacto. Los procesos de razonamiento informal desempean un papel importante en todas las ciencias. Como lo subrayan Helmer y Rescher. (En ciertas) ramas de Ia fsica , como partes de Ia aerodinmica y Ia fsica de temperaturas extremas, los procedimientos exactos aun estn intermezclados con la pericia no formal. Sin duda esta Ultima ser mas dominante, al retirarnos del ncleo preciso y generalmente bastante abstracto de una disciplina exacta hacia sus aplicaciones en las complejidades del mundo real. Tanto la arquitectura como Ia medicina son casos a propsito. Ambas tienen un contenido; es decir, son predictivas y explicativas Pueden por tanto llamarse apropiadamente ciencias, pero son bastante inexactas, ya que se basan en su mayor parte en procesos de razonamiento informal. La economa y la psicologa muestran abundantes pruebas de derivaciones ex actas as como confianza el juicio intuitivo. La intuicin y el juicio deben caracterizarse mas all de el producto de un sexto sentido, destellos de inspiracin, o disparos en la oscuridad. Churchman caracterizo el juicio como una opinin de grupo. El `grupo puede consistir del mismo individuo en diferentes puntos de su vida reflexiva, pero para propsitos prctico s, podemos hablar como si el grupo en cuestin tuviera diferentes miembros. Quisiramos argumentar que el juicio es un grupo de creencias que ocurre cuando existen diferencias de opinin entre los miembros del grupo, debido a que queremos decir que el juicio slido ocurre cuando este esta sujeto a una fuerte oposicin Por tanto, la esencia del concepto de juicio es el establecimiento de un acuerdo en el contexto de desacuerdos. El juicio es un tipo de negociacin el juicio es un grupo de creencias al que se llega por un conjunto de reglas que operan en las creencias (parcialmente conflictivas) de los miembros como individuos.; Creemos que estas reglas pueden operar consciente e inconscientemente, incluso ser desconocidas para los mismos individuos. Por tanto, cada individuo har un juicio como si fuera su propia creencia, pero un hecho real, es que esta creencia se ha formado y modelado al calor del debate y confrontacin con sus compaeros o asociados. La intuicin pertenece al mismo tipo de proceso de razonamiento que el juicio. La intuicin se define en el Websters como poder o facultad de obtener conocimiento directo sin pensamiento e inferencia racionales. La intuicin se asocia en el The saurus de Roget, con la ausencia de razonamiento. OBSERVACIONES Y DATOS COMPROBADOS

A fin de inferir la conducta de un proceso, deben hacerse muchas observaciones, antes de estar en posicin de hipotetizar la forma de la relacin entre las variables observadas. Sin embargo, el cientfico social no se beneficia de la replica, como lo hacen sus colegas en las ciencias fsicas. Estos ltimos pueden replicar su experimento en el laboratorio tantas veces como lo deseen. Si el economista analiza las causas de una recesion, debe estudiar los eventos como ocurren, o reconstruir el curso de los datos obtenidos en ese tiempo, la forma idntica de recesion nunca ocurrida nuevamente. En toda probabilidad el cientfico social debe hacer su hiptesis sobre la base de muy pocas observaciones. No cuentan con el beneficio de la replica. En unos cuantos casos, puede tratar de observar eventos similares, y estar preparado a hacerlo por adelantado. Por ejemplo, un socilogo puede observar un grupo de nios en el juego, para determinar sus hbitos de juego. Puede registrar el nmero de veces que tienen lugar ciertos eventos y obtener, por tanto, una distribucin de frecuencia. Despus de un cuidadoso anlisis, esto le puede conducir a una hiptesis sobre la conducta de la niez. Obviamente, dos eventos no son iguales, pero de alguna forma surge un patrn de la similitud entre los eventos. Un nmero de observaciones muy pequeo, no debe impedir hacer derivaciones significativas, referentes a las relaciones entre las variables observadas. En principio, la probabilidad objetiva demanda que se observe un evento un nmero infinito de veces. A pesar de esta advertencia, las estimaciones de probabilidad se hacen con menos que un nmero infinito de observaciones. Se ha desarrollado y aceptado una teora de probabilidad totalmente estructurada con base en probabilidades subjetivas. Las probabilidades subjetivas siguen las mismas reglas matemticas, como las probabilidades objetivas. Estas se basan en estimaciones subjetivas de la probabilidad de ocurrencia de un evento. Adems, esta teora admite que se modifiquen las estimaciones subjetivas, al hacerse disponible nueva informacin, que conduce a las revisiones de probabilidades a priori.

5.2 Metodologa de diseo de sistemas

Uno de los campos en donde con mas intensidad se ha sentido la necesidad de utilizar conceptos y metodologas de Ingeniera de Sistemas es en el desarrollo de tecnologa. Esto se debe a que los sistemas tcnicos, que sirven para satisfacer ciertas necesidades de los hombres, estn compuestos de elementos interconectados entre s de tal forma que se hace necesario pensar en trminos de sistemas, tanto para el desarrollo de nueva tecnologa como para el anlisis de la ya existente. METODOLOGA

Los pasos principales de la metodologa de Hall son: 1 Definicin del problema 2 Seleccin de objetivo 3 Sntesis de sistemas 4 Anlisis de sistemas 5 Seleccin del sistema 6 Desarrollo del sistema 7 Ingeniera 1. Definicin del Problema: se busca transformar una situacin confusa e indeterminada, reconocida como problemtica y por lo tanto indeseable, en un estatuto en donde se trate de definirla claramente. Esto sirve para: a) Establecer objetivos preliminares. b) El anlisis de distintos sistemas. De la definicin del problema los dems pasos de la metodologa dependen de cmo haya sido concebido y definido el problema. Si la definicin del problema es distinta a lo que realmente es, lo ms probable es que todo lo que se derive del estudio vaya a tener un impacto muy pobre en solucionar la verdadera situacin problemtica. La definicin del problema demanda tanta creatividad como el proponer soluciones. El nmero de posibles soluciones aumenta conforme el problema es definido en trminos ms amplios y que disminuyen al aumentar l numero de palabras que denotan restricciones dentro de la restriccin. Existen dos formas en cmo nacen los problemas que son resueltos con sistemas tcnicos: a) La bsqueda en el medio ambiente de nuevas ideas, teoras, mtodos, y materiales, para luego buscar formas de utilizarlos en la organizacin. b) Estudiar la organizacin actual y sus operaciones para detectar y definir necesidades. Estas dos actividades estn estrechamente relacionadas y se complementan una a otra. INVESTIGACIN DE NECESIDADES Las necesidades caen dentro de tres categoras.

a) Incrementar la funcin de un sistema. Hacer que un sistema realice mas funciones de las actuales. b) Incrementar el nivel de desempeo. Hacer que un sistema sea ms confiable. Ms fcil de operar y mantener, capaz de adaptarse a niveles estndares ms altos. c) Disminuir costos, hacer que un sistema sea ms eficiente. INVESTIGACIN DEL MEDIO AMBIENTE Se trata de entender y describir el medio ambiente en donde es encuentra la organizacin, entre otras cosas, se realiza un peinado del medio ambiente en bsquedas de nuevas ideas, mtodos, materiales y tecnologas que puedan ser utilizados en la satisfaccin de necesidades. De este ultimo se desprende que el criterio para decidir si algo que existe en le medio ambiente es til para la organizacin esta en funcin de las necesidades de esta ultima. 2. SELECCIN DE OBJETIVOS. Se establece tanto lo que esperamos del sistema como los criterios bajo los cuales mediremos su comportamiento y compararemos la efectividad de diferentes sistemas. Primero se establece que es lo que esperamos obtener del sistema, as como insumos y productos y las necesidades que este pretenda satisfacer. Ya que un sistema tcnico se encuentra dentro de un suprasistema que tiene propsitos, aquel debe ser evaluado en funcin de este. No es suficiente que el sistema ayude a satisfacer ciertas necesidades. Se debe escoger un sistema de valores relacionados con los propsitos de la organizacin, mediante el cual se pueda seleccionar un sistema entre varios y optimizarlo. Los valores ms comunes son: utilidad (dinero), mercado, costo, calidad, desempeo, compatibilidad, flexibilidad o adaptabilidad, simplicidad, seguridad y tiempo. Los objetivos deben ser operados hasta que sea claro como distintos resultados pueden ser ocasionados a ellos para seleccionar y optimizar un sistema tcnico. Cuando un sistema tiene varios objetivos que deben satisfacerse simultneamente, es necesario definir la importancia relativa de cada uno de ellos. Si cada objetivo debe cumplirse bajo una serie de valores a estos tambin debe a signarse un peso relativo que nos permita cambiarlos en el objetivo englobador. 3. SNTESIS DEL SISTEMA. Lo primero que se debe hacer es buscar todas las alternativas conocidas a travs de las fuentes de informacin a nuestro alcance. Si el problema a sido definido ampliamente, l nmero de alternativas va a ser bastante grande. De aqu se debe de obtener ideas para

desarrollar distintos sistemas que puedan ayudarnos a satisfacer nuestras necesidades. Una vez hecho esto, se procede a disear (ingeniar) distintos sistemas. En esta parte no se pretende que el diseo sea muy detallado. Sin embargo, debe de estar lo suficientemente detallado de tal forma que los distintos sistemas puedan ser evaluados. 3.1 DISEO FUNCIONAL El primer paso es listar los insumos y productos del sistema. Una vez hecho esto, se listan las funciones que se tienen que realizar para que dados ciertos insumos se obtengan ciertos productos. Estas funciones se realizan o sintetizan mostrando en un modelo esquemtico de las actividades y como stas se relacionan. Todo lo que se desea en este punto es ingeniar un sistema que trabaje, la optimizacin del mismo no importa tanto en este punto. 4. ANLISIS DE SISTEMAS. La funcin de anlisis es deducir todas las consecuencias relevantes de los distintos sistemas para seleccionar el mejor. La informacin que se obtiene en esta etapa s retroalimenta a las funciones de seleccin de objetivos y sntesis de sistema. Los sistemas se analizan en funcin de los objetivos que se tengan. 4.1 COMPARACIN DE SISTEMAS Una vez que todos los sistemas han sido analizados y sintetizados, el paso siguiente es obtener las discrepancias y similitudes que existen entre cada uno de ellos. Existen dos tipos de comparacin: a) Comparar el comportamiento de dos sistemas con respecto a un mismo objetivo. b) Comparar dos objetivos de un mismo sistema. Antes que se lleve a cabo la comparacin entre distintos sistemas, stos deben ser optimizados, deben estar diseados de tal forma que se operen lo ms eficientemente posible. No se pueden comparar dos sistemas si an no han sido optimizados. 5. SELECCIN DEL SISTEMA. Cuando el comportamiento de un sistema se puede predecir con certidumbre y solamente tenemos un solo valor dentro de nuestra funcin objetivo, el procedimiento de seleccin del sistema es bastante simple. Todo lo que se tiene que hacer es seleccionar el criterio de seleccin. Cuando el comportamiento del sistema no se puede predecir con certidumbre y se tienen distintos valores en funcin de los cuales se va a evaluar el sistema, no existe un procedimiento general mediante el cual se puede hacer la seleccin del sistema. 6. DESARROLLO DEL SISTEMA.

El desarrollo del sistema de un sistema sigue bsicamente el ciclo que se muestra en la siguiente figura. En base al diseo que se haba hecho del sistema durante la fase de sntesis del sistema, se hace un diseo detallado del mismo, para esto, se puede utilizar la tcnica del sntesis funcional, mencionado anteriormente. Una vez que el sistema esta en papel, hay que darle vida, desarrollarlo. l nmero de personas que toman parte en esta operacin depende de la magnitud del sistema. Por ejemplo, el production control sistem (PSC) desarrollado por la burroughs tiene invertido alrededor de 50 aos-hombre. Lgicamente, no se puede poner en operacin un sistema una vez que haya sido construido. Se tienen que hacer pruebas para deslumbrar problemas no previstos en su funcionamiento. En caso que no funcione como debiese, se debe investigar loas razones y tomar acciones correctivas. Estas caen dentro de dos categoras: a) Fallas en el diseo. b) Fallas en la construccin. En el primer caso, debe reportarse que fallas tiene el diseo del sistema para proceder a hacer los cambios. En el segundo caso, debe reportarse que es lo que se construy mal para proceder a corregirlo. Una vez que el sistema funcione como se pretenda, y antes de que se ponga en operacin, deben de desarrollarse documentos que contengan informacin sobre su operacin, instalacin, mantenimiento, etc. 7. INGENIERA. En esta etapa no consiste en un conjunto de pasos ms o menos secuenciales como en otras partes del proceso. Consiste en varios trabajos los cuales puedan ser calificados de la siguiente forma: a) Vigilar la operacin del nuevo sistema para mejoras en diseos futuros. b) Corregir fallas en el diseo. c) Adaptar el sistema a cambios del medio ambiente. d) Asistencia al cliente. Esta etapa dura mientras el sistema esta en operacin. METODOLOGIA DE JENKINS Ingeniera de Sistemas no es una nueva disciplina, ya que tiene sus races en la prctica de la Ingeniera Industrial. Sin embargo, enfatiza el desempeo global del sistema como un todo, en contraposicin al desempeo de partes individuales del sistema. Una caracterstica

importante de la Ingeniera de Sistemas es el desarrollo de modelos cuantitativos, de tal forma que una medida de desempeo del sistema pueda optimizarse. La palabra Ingeniera en Ingeniera de Sistemas se usa en el sentido de disear, construir y operar sistemas, esto es, ingeniar sistemas. Otra de las caractersticas de la Ingeniera de Sistemas es la posibilidad de poder contemplar a travs de su metodologa, la solucin de problemas completamente diferentes que provienen de reas muy diferentes como la tecnologa y la administracin, enfatizando sus caractersticas comunes a travs de isomorfismos que puedan relacionarlos. Es por esto que cuando la Ingeniera de Sistemas se aplica a la solucin de problemas complejos, incluye la participacin de profesionales en reas muy diferentes y no slo la participacin de ingenieros. UNA METODOLOGA DE INGENIERA DE SISTEMAS Un enfoque de sistemas a la solucin de problemas En esta seccin se proporcionan las lneas de gua generales que usara un Ingeniero para confrontar y solucionar problemas. Las diferentes etapas que se describen posteriormente, representan un desglose de las cuatro fases siguientes: FASE 1: Anlisis de Sistemas El Ingeniero inicia su actividad con un anlisis de lo que est sucediendo y por qu est sucediendo, as como tambin de cmo puede hacerse mejor. De esta manera el sistema y sus objetivos podrn definirse, de forma tal que resuelva el problema identificado. ANALISIS DE SISTEMAS Identificacin y formulacin del problema Organizacin del proyecto Definicin del sistema Definicin del suprasistema Definicin de los objetivos del suprasistema Definicin de los objetivos del sistema Definicin de las medidas de desempeo del sistema Recopilacin de datos e informacin FASE 2: Diseo de Sistemas

Primeramente se pronostica el ambiente futuro del sistema. Luego se desarrolla un modelo cuantitativo del sistema y se usa para simular o explorar formas diferentes de operarlo, creando de esta manera alternativas de solucin. Por ltimo, en base a una evaluacin de las alternativas generadas, se selecciona la que optimice la operacin del sistema. SISTEMADISEO DE Pronsticos Modelacin y simulacin del sistema Optimizacin de la operacin del sistema Control de la operacin del sistema Confiabilidad del sistema FASE 3: Implantacin de Sistemas Los resultados del estudio deben presentarse a los tomadores de decisiones y buscar aprobacin para la implantacin del diseo propuesto. Posteriormente, tendr que construirse en detalle el sistema. En esta etapa del proyecto se requerir de una planeacin cuidadosa que asegure resultados exitosos. Despus de que el sistema se haya diseado en detalle, tendr que probarse para comprobar el buen desempeo de su operacin, confiabilidad, etc. SISTEMASIMPLANTACIN DE Documentacin y autorizacin del sistema Construccin e instalacin del sistema FASE 4: Operacin y Apreciacin Retrospectiva de Sistemas Despus de la fase de implantacin se llegar al momento de liberar el sistema diseado y entregarlo a los que lo van a operar. Es en esta fase donde se requiere mucho cuidado para no dejar lugar a malos entendimientos en las personas que van a operar el sistema, y generalmente representa el rea ms descuidada en el proyecto de diseo. Por ltimo, la eficiencia de la operacin del sistema debe apreciarse, dado que estar operando en un ambiente dinmico y cambiante que probablemente tendr caractersticas diferentes a las que tena cuando el sistema fue diseado. En caso de que la operacin del sistema no sea satisfactoria en cualquier momento posterior a su liberacin, tendr que iniciarse la fase 1 de la metodologa, identificando los problemas que obsoletizaron el sistema diseado. APRECIACIN RETROSPECTIVA DE SISTEMASOPERACIN Y

Operacin inicial del sistema Apreciacin retrospectiva de la operacin del sistema Mejoramiento de la operacin del sistema diseado.

5.3 plicaciones

5.4 APLICACIONES Una interfaz de programacin de aplicaciones o API (del ingls Application Programming Interface) es el conjunto de funciones y procedimientos (o mtodos, si se refiere a programacin orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstraccin. Caractersticas Una API representa una interfaz de comunicacin entre componentes de software. Se trata del conjunto de llamadas a ciertas bibliotecas que ofrecen acceso a ciertos servicios desde los procesos y representa un mtodo para conseguir abstraccin en la programacin, generalmente (aunque no necesariamente) entre los niveles o capas inferiores y los superiores del software. Uno de los principales propsitos de una API consiste en proporcionar un conjunto de funciones de uso general, por ejemplo, para dibujar ventanas o iconos en la pantalla. De esta forma, los

programadores se benefician de las ventajas de la API haciendo uso de su funcionalidad, evitndose el trabajo de programar todo desde el principio. Las APIs asimismo son abstractas: el software que proporciona una cierta API generalmente es llamado la implementacin de esa API. Por ejemplo, se puede ver la tarea de escribir Hola Mundo sobre la pantalla en diferentes niveles de abstraccin: 1. Haciendo todo el trabajo desde el principio: 1. Traza, sobre papel milimetrado, la forma de las letras (y espacio) H,o, l, a,M,u, n, d, o. 2. Crea una matriz de cuadrados negros y blancos que se asemeje a la sucesin de letras. 3. Mediante instrucciones en ensamblador, escribe la informacin de la matriz en la memoria intermedia (buffer) de pantalla.

4. Mediante la instruccin adecuada, haz que la tarjeta grfica realice el volcado de esa informacin sobre la pantalla. 2. Por medio de un sistema operativo para hacer parte del trabajo: 1. Carga una fuente tipogrfica proporcionada por el sistema operativo. 2. Haz que el sistema operativo borre la pantalla. 3. Haz que el sistema operativo dibuje el texto Hola Mundo usando la fuente cargada. 3. Usando una aplicacin (que a su vez usa el sistema operativo) para realizar la mayor parte del trabajo: 1. Escribe un documento HTML con las palabras Hola Mundo para que un navegador Web como Mozilla, Firefox, Opera o Internet Explorer pueda representarlo en el monitor. Como se puede ver, la primera opcin requiere ms pasos, cada uno de los cuales es mucho ms complicado que los pasos de las opciones siguientes. Adems, no resulta nada prctico usar el primer planteamiento para representar una gran cantidad de informacin, como un artculo enciclopdico sobre la pantalla, mientras que el segundo enfoque simplifica la tarea eliminando un paso y haciendo el resto ms sencillos y la tercera forma simplemente requiere escribir Hola Mundo. Sin embargo, las APIs de alto nivel generalmente pierden flexibilidad; por ejemplo, resulta mucho ms difcil en un navegador web hacer girar texto alrededor de un punto con un contorno parpadeante que programarlo a bajo nivel. Al elegir usar una API se debe llegar a un cierto equilibrio entre su potencia y simplicidad y su prdida de flexibilidad.