s5 - Analisis - de - Sistemas - I PDF

FACULTAD DE CIENCIAS Y TECNOLOGIA
RED NACIONAL UNIVERSITARIA
SYLLABUS Facultad de Ciencias y Tecnologa

Ingeniera de Sistemas
QUINTO SEMESTRE ANLISIS DE SISTEMAS I

Gestin Acadmica I / 2011
Syllabus elaborado por: Ing. Reynaldo Einar Zabaleta Rioja
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
UDABOL
UNIVERSIDAD DE AQUINO BOLIVIA Acreditada como PLENA mediante R.M. 288/01
VISIN DE LA UNIVERSIDAD Ser la Universidad lder en calidad educativa.
MISIN DE LA UNIVERSIDAD Desarrollar la Educacin Superior Universitaria con calidad y competitividad al servicio de la sociedad.
Estimado(a) estudiante: El Syllabus que ponemos en tus manos es el fruto del trabajo intelectual de tus docentes, quienes han puesto sus mejores empeos en la planificacin de los procesos de enseanza para brindarte una educacin de la mas alta calidad. Este documento te servir de gua para que organices mejor tus procesos de aprendizaje y los hagas mucho ms productivos. Esperamos que sepas apreciarlo y cuidarlo.
SYLLABUS
U N I V E R S I D A D D E A Q U I N O B O L I V I A
I.
Asignatura: Cdigo: Requisito: Carga Horaria: Horas tericas: Horas prcticas: Crditos:
ANLISIS DE SISTEMAS I CMP 316 CMP 228 80 Horas 60 Horas 20 Horas 8
II. OBJETIVOS GENERALES DE LA ASIGNATURA. Dotar al estudiante de los conocimientos bsicos del Anlisis de Sistemas, buscando fortalecer la conceptualizacin y concepcin de sistemas a travs de casos concretos. Brindar un conocimiento terico sobre lo que constituye el anlisis y diseo de sistemas de informacin, sus mtodos, tcnicas y herramientas. Ensear al alumno a disear un sistema hasta la fase de prototipo, mediante la tcnica del anlisis estructurado y pasando por el uso de diferentes tcnicas como el ISAC, el WBS, la planificacin mediante una herramienta informtica, etc. Lograr un primer prototipo de un sistema de informacin adems de la documentacin pertinente al tema mediante la tcnica del anlisis estructurado.
III. PROGRAMA ANALTICO DE LA ASIGNATURA. UNIDAD I. Introduccin al Anlisis de Sistemas TEMA 1. Introduccin al Enfoque de Sistemas 1.1 1.2 1.3 1.4 1.5 1.6 Introduccin Aportes semnticos Aportes metodolgicos Las organizaciones como sistemas Metodologa de aplicacin de la T.G.S., para el anlisis y diseo de sistemas El sistema de control
TEMA 2. El ciclo de vida y paradigma tradicional del desarrollo de sistemas 2.1 2.1.1 2.1.2 2.1.3 2.1.3.1 2.1.3.2 2.1.3.3 2.1.4 2.1.5 2.1.6 2.1.7 2.1.8 2.1.9 Ciclo de vida del desarrollo de sistemas Investigaciones preliminares Clarificacin del requerimiento Estudio de factibilidad Factibilidad tcnica Factibilidad econmica Factibilidad operativa Aprobacin del requerimiento Determinacin de requerimientos Desarrollo del sistema prototipo Diseo del sistema Desarrollo del software Prueba de los sistemas
2.1.10 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.3 2.3.1 2.3.2 2.3.3
Puesta en marcha Investigaciones preliminares Alcance del estudio Realizacin de la investigacin Prueba de factibilidad del proyecto Manejo de proyectos no factibles Determinacin de requerimientos Qu es la determinacin de requerimientos? Requerimientos bsicos Requerimientos de transacciones de los usuarios
UNIDAD II. Muestreo de Datos y Gestin de Proyectos TEMA 3. Muestreo y la Investigacin de Datos 3.1 Introduccin 3.2 El diseo del muestreo 3.3 Tipos de datos e informacin que se obtiene durante la investigacin 3.4 La entrevista y el cuestionario 3.5 Tipos de preguntas 3.6 Delimitar la poblacin sujeta a seleccin de muestras 3.7 Planeacin para el uso de cuestionarios 3.8 Elegir el tipo de muestra 3.9 Decidir el tamao de la muestra TEMA 4. Gestin de proyectos - Proyecto de Anlisis de Sistemas con Microsoft Project 4.1 La administracin de proyectos 4.2 Microsoft Project 2000 4.3 Tringulo del Proyecto 4.4 Base de datos de Microsoft Project 4.5 Definir un proyecto 4.6 El ambiente de trabajo de Microsoft Project 2000 4.7 La tabla de tareas y el rea de grfico. UNIDAD III. Determinacin de Requerimientos y Anlisis Estructurado TEMA 5. Determinacin de Requerimientos - Mtodo ISAC (Information Systems Work and Analysis of Changes) 5.1 El Mtodo ISAC 5.2 Componentes del ISAC 5.3 Tareas de los componentes del ISAC 5.4 Diagrama de actividades 5.5 Definir necesidades de cambio. 5.6 Generar alternativas de cambio 5.7 Evaluar alternativas 5.8 Clasificacin de los sub sistemas de informacin deseados 5.9 Cobertura de ISAC de los niveles de agregacin 5.10 ISAC anlisis de cambio y el ciclo de ingeniera 5.11 Especificar los requerimientos de los sub sistemas
TEMA 6. Anlisis Estructurado Estrategia de Flujo de Datos 6.1 Esttico o no: he aqu el dilema 6.2 Anlisis estructurado 6.3 Caracterstica de la estrategia de flujo de datos 6.4 Desarrollo de los diagramas de flujo de datos 6.5 Reglas generales para el dibujo de diagramas lgicos de flujo de datos 6.6 Caractersticas del diccionario de datos 6.7 Registro de las descripciones de datos UNIDAD IV. Principios del Diseo de Sistemas TEMA 7. Principios y Mtodos de Diseo de Sistemas Herramientas de Desarrollo 7.1 Introduccin 7.2 Modelo de Datos 7.3 Modelo Entidad Relacin 7.4 Modelo Relacional 7.5 Gestores de Base de Datos Relacionales - Herramientas 7.6 DDL 7.7 DCL 7.8 MDL 7.9 Diseo de pantallas 7.10 Prototipo del sistema 7.11 Pruebas al sistema IV. SISTEMA DE EVALUACIN DE APRENDIZAJES. El sistema de evaluacin hace hincapi en varios tipos de calificacin: Diagnstica: es la evaluacin de los saberes o conocimientos previos de los y las estudiantes, as como de sus ritmos y estilos de aprendizaje y sus tipos de inteligencia, que sirve al docente como punto de partida para, el desarrollo curricular, para la mejor organizacin y estructuracin de las secuencias de aprendizaje, de modo que estas tengan en cuenta no slo el punto de partida del grupo con el que trabajar durante el semestre sino adems las diferencias y especificidades de cada estudiante para que los aprendizajes resulten ms efectivos y permitan el ptimo desarrollo integral de cada uno(a). Procesual o de desempeo o formativa: en esta forma de evaluacin se valora el avance del o de la estudiante de su nivel de desarrollo real (detectado mediante la evaluacin diagnstica) a su nivel de desarrollo potencial (detectado mediante diversas actividades o tareas). Esta forma de evaluacin, por su naturaleza, es eminentemente cualitativa aunque puede ser valorada cuantitativamente mediante un sistema de puntaje que permita apreciar los avances del o de la estudiante en su zona de desarrollo prximo (zdp) (o, incluso, fuera de ella, en el caso de que el proceso de aprendizaje rebase la misma y d lugar a nuevas zdp). La ponderacin de la asignatura de Arquitectura de Computadoras dentro la Evaluacin Procesual, contempla la realizacin de actividades formativas a desarrollar (Work Papers, Difs, Participacin, evaluacin diaria, Investigacin, Congresos, y Seminarios) y su calificacin es sobre el 50 % de la calificacin del primer y segundo parcial, estimando un promedio de todas las actividades. La ponderacin de esta evaluacin es el promedio de todas las actividades desarrolladas (Work Papers, Dif s,
Participacin, Laboratorio, Investigacin, Congresos, Jornadas Cientficas, Aula Abierta y Seminarios) y su calificacin es sobre el 50 % de la calificacin del primer y segundo parcial. De resultados del proceso de aprendizaje: es la valoracin de los resultados de los procesos de aprendizaje del o de la, estudiante durante el semestre. Esta forma de evaluacin es tanto cualitativa como cuantitativa, por su naturaleza y por la funcin que cumple dentro de la evaluacin. La evaluacin de resultados en la asignatura especfica se llevar a cabo de forma terica y prctica aplicada a sistemas reales. La ponderacin de esta evaluacin es sobre 50 % de la calificacin del primer y segundo parcial, en el caso del examen final es de 100%, que por disposiciones actuales esta dividido en 50% como prueba final y 50% procesual. . EVALUACION PARCIAL 1 PARCIAL 2 FINAL PROCESUAL 50% 50% 50% DE RESULTADO 50% 50% 50% TOTAL 100% 100% 100% 100%
EVALUACION FINAL PROMEDIO PARCIAL 1, 2 Y FINAL
V. BIBLIOGRAFA. Bibliografa bsica SENN JAMES, Anlisis de Sistemas de Informacin. Ed. McGraw Hill, Bogot, 1999. KENDALL & KENDALL, Anlisis y Diseo de Sistemas, Ed. Prentice Hall, Mxico, 2005. PRESSMAN S. ROGER, Ingeniera de Software, Ed. McGraw Hill, Bogot, 1997. LAUDON, LUDON, Administracin de Sistemas de Informacin, Ed. Prentice may, Mxico, 1996. APUNTES: Adicionalmente el estudiante dispondr de los Work papers y DIFs entregados por la docente, los que forman parte del texto de la asignatura.
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
VI. PLAN CALENDARIO

UNIVERSIDAD DE AQUINO-BOLIVIA UNIDAD ACADMICA DE ORURO
CALENDARIO ACADMICO
GESTIN I/2011 TURNOS REGULAR-TRABAJO ESTUDIANTES NUEVOS-ANTIGUOS
SEMANA 1ra. 2da. 3ra. 4ta. 5ta. 6ta. 7ma. 8va. 9na. 10ma. 11ra. 12da. 13ra. 14ta. 15ta. 16ta. 17ma. 18va. 19na. 20va. 21ra. DEL 09-Mar 14-Mar 21-Mar 28-Mar 04-Abr 11-Abr 18-Abr 25-Abr 02-May 09-May 16-May 23-May 30-May 06-Jun 13-Jun 20-Jun 27-Jun 04-Jul 11-Jul 18-Jul 25-Jul AL 12-Mar 19-Mar 26-Mar 02-Abr 09-Abr 16-Abr 23-Abr 30-Abr 07-May 14-May 21-May 28-May 04-Jun 11-Jun 18-Jun 25-Jun 02-Jul 09-Jul 16-Jul 23-Jul 26-Jul Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia ACTIVIDADES TEMA 1. Introduccin al Enfoque de Sistemas TEMA 2. El ciclo de vida y paradigma tradicional del desarrollo de sistemas TEMA 2. El ciclo de vida y paradigma tradicional del desarrollo de sistemas TEMA 3. Muestreo y la Investigacin de Datos TEMA 4. Gestin de proyectos Inicio Primera Evaluacin Parcial Conclusin Primera Evaluacin Parcial TEMA 4. Gestin de proyectos TEMA 5. Determinacin de Requerimientos TEMA 6. Anlisis Estructurado TEMA 6. Anlisis Estructurado Inicio Segunda Evaluacin Parcial Conclusin Segunda Evaluacin Parcial TEMA 7. Principios y Mtodos de Diseo de Sistemas TEMA 7. Principios y Mtodos de Diseo de Sistemas TEMA 7. Herramientas de Desarrollo TEMA 7. Herramientas de Desarrollo Inicio Evaluacin Final Conclusin Evaluacin Final Evaluacin del segundo turno Cierre de Gestin FERIADOS 22 de abril 1 de mayo 23 de junio Viernes Santo Da del Trabajo Corpus Christi Presentacin de Notas Transcripcin de Notas Transcripcin de Notas Presentacin de Notas Presentacin de Notas Presentacin de Notas Presentacin de Notas OBSERVACIONES
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
VII. CONTROL DE EVALUACIONES 1 evaluacin parcial Fecha: Nota: 2 evaluacin parcial Fecha: Nota: Examen final Fecha: Nota: APUNTES
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
WORK PAPER # 1
PROGRAMA DE CONTROL DE CALIDAD
No. DE PROCEDIMIENTO: APRO 07
No. DE HOJAS: 11
ELABOR: Ing. Yubitza Adela Quintanilla Guzmn
CDIGO: CMP 316
TTULO DEL WORK PAPER: Introduccin al Enfoque de Sistemas DPTO.: Facultad de Ingeniera UDABOL ORURO DESTINADO A: DOCENTES ALUMNOS X ADMINIST. OTROS
OBSERVACIONES: Asignatura Anlisis de Sistemas I, Carrera Ingeniera de Sistemas, Unidad I, Tema 1
FECHA DE DIFUSIN: Marzo 2011
FECHA DE ENTREGA: Marzo 2011
INTRODUCCION AL ANLISIS DE SISTEMAS

Introduccin El enfoque de sistemas, facilita la unificacin de muchos campos del conocimiento. Dicho enfoque ha sido usado por las ciencias fsicas, biolgicas y sociales, como marco de referencia para la integracin de la teora organizacional moderna. El primer expositor de la Teora General de los Sistemas fue Ludwing Von Bertalanffy, en el intento de lograr una metodologa integradora para el tratamiento de problemas cientficos. La meta de la Teora General de los Sistemas no es buscar analogas entre las ciencias, sino tratar de evitar la superficialidad cientfica que ha estancado a las ciencias. Para ello emplea como instrumento, modelos utilizables y transferibles entre varios continentes cientficos, toda vez que dicha extrapolacin sea posible e integrable a las respectivas disciplinas. La Teora General de los Sistemas se basa en dos pilares bsicos: aportes semnticos y aportes metodolgicos. Aportes Semnticos: Las sucesivas especializaciones de las ciencias obligan a la creacin de nuevas palabras, estas se acumulan durante sucesivas especializaciones, llegando a formar casi un verdadero lenguaje que slo es manejado por los especialistas. De esta forma surgen problemas al tratarse de proyectos interdisciplinarios, ya que los participantes del proyecto son especialistas de diferentes ramas de la ciencia y cada uno de ellos maneja una semntica diferente a los dems. La Teora de los Sistemas, para solucionar estos inconvenientes, pretende introducir una semntica cientfica de utilizacin universal. Sistema: Es un conjunto organizado de cosas o partes interactuantes e interdependientes, que se relacionan formando un todo unitario y complejo. Cabe aclarar que las cosas o partes que componen al sistema, no se refieren al campo fsico (objetos), sino ms bien al funcional. De este modo las cosas o partes pasan a ser funciones bsicas realizadas por el sistema. Podemos enumerarlas en: entradas, procesos y salidas. Entradas: Las entradas son los ingresos del sistema que pueden ser recursos materiales, recursos humanos o informacin. Las entradas constituyen la fuerza de arranque que suministra al sistema sus necesidades operativas. Las entradas pueden ser: en serie: es el resultado o la salida de un sistema anterior con el cual el sistema en estudio est relacionado en forma directa. aleatoria: es decir, al azar, donde el termino "azar" se utiliza en el sentido estadstico. Las entradas aleatorias representan entradas potenciales para un sistema. retroaccin: es la reintroduccin de una parte de las salidas del sistema en s mismo. Proceso:
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
10
El proceso es lo que transforma una entrada en salida, como tal puede ser una mquina, un individuo, una computadora, un producto qumico, una tarea realizada por un miembro de la organizacin, etc. En la transformacin de entradas en salidas debemos saber siempre como se efecta esa transformacin. Con frecuencia el procesador puede ser diseado por el administrador. En tal caso, este proceso se denomina "caja blanca". No obstante, en la mayor parte de las situaciones no se conoce en sus detalles el proceso mediante el cual las entradas se transforman en salidas, porque esta transformacin es demasiado compleja. Diferentes combinaciones de entradas o su combinacin en diferentes rdenes de secuencia pueden originar diferentes situaciones de salida. En tal caso la funcin de proceso se denomina una "caja negra". Caja Negra: La caja negra se utiliza para representar a los sistemas cuando no sabemos que elementos o cosas componen al sistema o proceso, pero sabemos que a determinadas corresponden determinadas salidas y con ello poder inducir, presumiendo que a determinados estmulos, las variables funcionaran en cierto sentido. Salidas: Las salidas de los sistemas son los resultados que se obtienen de procesar las entradas. Al igual que las entradas estas pueden adoptar la forma de productos, servicios e informacin. Las mismas son el resultado del funcionamiento del sistema o, alternativamente, el propsito para el cual existe el sistema. Las salidas de un sistema se convierten en entrada de otro, que la procesar para convertirla en otra salida, repitindose este ciclo indefinidamente. Relaciones: Las relaciones son los enlaces que vinculan entre s a los objetos o subsistemas que componen a un sistema complejo. Podemos clasificarlas en: Simbiticas: es aquella en que los sistemas conectados no pueden seguir funcionando solos. A su vez puede subdividirse en unipolar o parasitaria, que es cuando un sistema (parsito) no puede vivir sin el otro sistema (planta); y bipolar o mutual, que es cuando ambos sistemas dependen entre si. Sinrgica: es una relacin que no es necesaria para el funcionamiento pero que resulta til, ya que su desempeo mejora sustancialmente al desempeo del sistema. Sinergia significa "accin combinada". Sin embargo, para la teora de los sistemas el trmino significa algo ms que el esfuerzo cooperativo. En las relaciones sinrgicas la accin cooperativa de subsistemas semi - independientes, tomados en forma conjunta, origina un producto total mayor que la suma de sus productos tomados de una manera independiente. Superflua: Son las que repiten otras relaciones. La razn de las relaciones superfluas es la confiabilidad. Las relaciones superfluas aumentan la probabilidad de que un sistema funcione todo el tiempo y no una parte del mismo. Estas relaciones tienen un problema que es su costo, que se suma al costo del sistema que sin ellas puede funcionar. Atributos: Los atributos de los sistemas, definen al sistema tal como lo conocemos u observamos. Los atributos pueden ser definidores o concomitantes: los atributos definidores son aquellos sin los cuales una entidad no sera designada o definida tal como se lo hace; los atributos concomitantes en cambio son aquellos que cuya presencia o ausencia no establece ninguna diferencia con respecto al uso del trmino que describe la unidad.
11
Contexto: Un sistema siempre estar relacionado con el contexto que lo rodea, o sea, el conjunto de objetos exteriores al sistema, pero que influyen decididamente a ste, y a su vez el sistema influye, aunque en una menor proporcin, influye sobre el contexto; se trata de una relacin mutua de contexto-sistema. Tanto en la Teora de los Sistemas como en el mtodo cientfico, existe un concepto que es comn a ambos: el foco de atencin, el elemento que se asla para estudiar. El contexto a analizar depende fundamentalmente del foco de atencin que se fije. Ese foco de atencin, en trminos de sistemas, se llama lmite de inters. Para determinar este lmite se consideraran dos etapas por separado: a) La determinacin del contexto de inters. b) La determinacin del alcance del lmite de inters entre el contexto y el sistema. a) Se suele representar como un crculo que encierra al sistema, y que deja afuera del lmite de inters a la parte del contexto que no interesa al analista. d) En lo que hace a las relaciones entre el contexto y los sistemas y viceversa. Es posible que slo interesen algunas de estas relaciones, con lo que habr un lmite de inters relacional. Determinar el lmite de inters es fundamental para marcar el foco de anlisis, puesto que slo ser considerado lo que quede dentro de ese lmite. Entre el sistema y el contexto, determinado con un lmite de inters, existen infinitas relaciones. Generalmente no se toman todas, sino aquellas que interesan al anlisis, o aquellas que probabilsticamente presentan las mejores caractersticas de prediccin cientfica. Rango: En el universo existen distintas estructuras de sistemas y es factible ejercitar en ellas un proceso de definicin de rango relativo. Esto producira una jerarquizacin de las distintas estructuras en funcin de su grado de complejidad. Cada rango o jerarqua marca con claridad una dimensin que acta como un indicador claro de las diferencias que existen entre los subsistemas respectivos. Esta concepcin denota que un sistema de nivel 1 es diferente de otro de nivel 8 y que, en consecuencia, no pueden aplicarse los mismos modelos, ni mtodos anlogos a riesgo de cometer evidentes falacias metodolgicas y cientficas. Para aplicar el concepto de rango, el foco de atencin debe utilizarse en forma alternativa: se considera el contexto y a su nivel de rango o se considera al sistema y su nivel de rango. Refirindonos a los rangos hay que establecer los distintos subsistemas. Cada sistema puede ser fraccionado en partes sobre la base de un elemento comn o en funcin de un mtodo lgico de deteccin. El concepto de rango indica la jerarqua de los respectivos subsistemas entre s y su nivel de relacin con el sistema mayor. Subsistemas: En la misma definicin de sistema, se hace referencia a los subsistemas que lo componen, cuando se indica que el mismo
12
esta formado por partes o cosas que forman el todo. Estos conjuntos o partes pueden ser a su vez sistemas (en este caso seran subsistemas del sistema de definicin), ya que conforman un todo en s mismos y estos seran de un rango inferior al del sistema que componen. Estos subsistemas forman o componen un sistema de un rango mayor, el cual para los primeros se denomina macrosistema. Variables: Cada sistema y subsistema contiene un proceso interno que se desarrolla sobre la base de la accin, interaccin y reaccin de distintos elementos que deben necesariamente conocerse. Dado que dicho proceso es dinmico, suele denominarse como variable, a cada elemento que compone o existe dentro de los sistemas y subsistemas. Pero no todo es tan fcil como parece a simple vista ya que no todas las variables tienen el mismo comportamiento sino que, por lo contrario, segn el proceso y las caractersticas del mismo, asumen comportamientos diferentes dentro del mismo proceso de acuerdo al momento y las circunstancias que las rodean. Parmetro: Uno de los comportamientos que puede tener una variable es el de parmetro, que es cuando una variable no tiene cambios ante alguna circunstancia especfica, no quiere decir que la variable es esttica ni mucho menos, ya que slo permanece inactiva o esttica frente a una situacin determinada. Operadores: Otro comportamiento es el de operador, que son las variables que activan a las dems y logran influir decisivamente en el proceso para que este se ponga en marcha. Se puede decir que estas variables actan como lderes de las restantes y por consiguiente son privilegiadas respecto a las dems variables. Cabe aqu una aclaracin: las restantes variables no solamente son influidas por los operadores, sino que tambin son influenciadas por el resto de las variables y estas tienen tambin influencia sobre los operadores. Retroalimentacin: La retroalimentacin se produce cuando las salidas del sistema o la influencia de las salidas del sistema en el contexto, vuelven a ingresar al sistema como recursos o informacin. La retroalimentacin permite el control de un sistema y que el mismo tome medidas de correccin en base a la informacin retroalimentada. Feed-forward o alimentacin delantera: Es una forma de control de los sistemas, donde dicho control se realiza a la entrada del sistema, de tal manera que el mismo no tenga entradas corruptas o malas, de esta forma al no haber entradas malas en el sistema, las fallas no ser consecuencia de las entradas sino de los proceso mismos que componen al sistema. Homeostasis y entropa: La homeostasis es la propiedad de un sistema que define su nivel de respuesta y de adaptacin al contexto.
13
Es el nivel de adaptacin permanente del sistema o su tendencia a la supervivencia dinmica. Los sistemas altamente homeostticos sufren transformaciones estructurales en igual medida que el contexto sufre transformaciones, ambos actan como condicionantes del nivel de evolucin. La entropa de un sistema es el desgaste que el sistema presenta por el transcurso del tiempo o por el funcionamiento del mismo. Los sistemas altamente entrpicos tienden a desaparecer por el desgaste generado por su proceso sistmico. Los mismos deben tener rigurosos sistemas de control y mecanismos de revisin, reelaboracin y cambio permanente, para evitar su desaparicin a travs del tiempo. En un sistema cerrado la entropa siempre debe ser positiva. Sin embargo en los sistemas abiertos biolgicos o sociales, la entropa puede ser reducida o mejor aun transformarse en entropa negativa, es decir, un proceso de organizacin ms completa y de capacidad para transformar los recursos. Esto es posible porque en los sistemas abiertos los recursos utilizados para reducir el proceso de entropa se toman del medio externo. Asimismo, los sistemas vivientes se mantienen en un estado estable y pueden evitar el incremento de la entropa y aun desarrollarse hacia estados de orden y de organizacin creciente. Permeabilidad: La permeabilidad de un sistema mide la interaccin que este recibe del medio, se dice que a mayor o menor permeabilidad del sistema el mismo ser ms o menos abierto. Los sistemas que tienen mucha relacin con el medio en el cul se desarrollan son sistemas altamente permeables, estos y los de permeabilidad media son los llamados sistemas abiertos. Por el contrario los sistemas de permeabilidad casi nula se denominan sistemas cerrados. Integracin e independencia: Se denomina sistema integrado a aquel en el cual su nivel de coherencia interna hace que un cambio producido en cualquiera de sus subsistemas produzca cambios en los dems subsistemas y hasta en el sistema mismo. Un sistema es independiente cuando un cambio que se produce en l, no afecta a otros sistemas. Centralizacin y descentralizacin: Un sistema se dice centralizado cuando tiene un ncleo que comanda a todos los dems, y estos dependen para su activacin del primero, ya que por s solos no son capaces de generar ningn proceso. Por el contrario los sistemas descentralizados son aquellos donde el ncleo de comando y decisin est formado por varios subsistemas. En dicho caso el sistema no es tan dependiente, sino que puede llegar a contar con subsistemas que actan de reserva y que slo se ponen en funcionamiento cuando falla el sistema que debera actuar en dicho caso. Los sistemas centralizados se controlan ms fcilmente que los descentralizados, son ms sumisos, requieren menos recursos, pero son ms lentos en su adaptacin al contexto. Por el contrario los sistemas descentralizados tienen una mayor velocidad de respuesta al medio ambiente pero requieren mayor cantidad de recursos y mtodos de coordinacin y de control ms elaborados y complejos. Adaptabilidad: Es la propiedad que tiene un sistema de aprender y modificar un proceso, un estado o una caracterstica de acuerdo a las modificaciones que sufre el contexto. Esto se logra a travs de un mecanismo de adaptacin que permita responder a los cambios internos y externos a travs del tiempo.
14
Para que un sistema pueda ser adaptable debe tener un fluido intercambio con el medio en el que se desarrolla. Mantenibilidad: Es la propiedad que tiene un sistema de mantenerse constantemente en funcionamiento. Para ello utiliza un mecanismo de mantenimiento que asegure que los distintos subsistemas estn balanceados y que el sistema total se mantiene en equilibrio con su medio. Estabilidad: Un sistema se dice estable cuando puede mantenerse en equilibrio a travs del flujo continuo de materiales, energa e informacin. La estabilidad de los sistemas ocurre mientras los mismos pueden mantener su funcionamiento y trabajen de manera efectiva (mantenibilidad). Armona: Es la propiedad de los sistemas que mide el nivel de compatibilidad con su medio o contexto. Un sistema altamente armnico es aquel que sufre modificaciones en su estructura, proceso o caractersticas en la medida que el medio se lo exige y es esttico cuando el medio tambin lo es. Optimizacin y sub-optimizacin: Optimizacin modificar el sistema para lograr el alcance de los objetivos. Suboptimizacin en cambio es el proceso inverso, se presenta cuando un sistema no alcanza sus objetivos por las restricciones del medio o porque el sistema tiene varios objetivos y los mismos son excluyentes, en dicho caso se deben restringir los alcances de los objetivos o eliminar los de menor importancia si estos son excluyentes con otros ms importantes. Exito: El xito de los sistemas es la medida en que los mismos alcanzan sus objetivos. La falta de xito exige una revisin del sistema ya que no cumple con los objetivos propuestos para el mismo, de modo que se modifique dicho sistema de forma tal que el mismo pueda alcanzar los objetivos determinados. APORTES METODOLOGICOS Jerarqua de los sistemas Al considerar los distintos tipos de sistemas del universo Kennet Boulding proporciona una clasificacin til de los sistemas donde establece los siguientes niveles jerrquicos: 1. Primer nivel, estructura esttica. Se le puede llamar nivel de los marcos de referencia. 2. Segundo nivel, sistema dinmico simple. Considera movimientos necesarios y predeterminados. Se puede denominar reloj de trabajo. 3. Tercer nivel, mecanismo de control o sistema ciberntico. El sistema se autorregula para mantener su equilibrio. 4. Cuarto nivel, "sistema abierto" o auto estructurado. En este nivel se comienza a diferenciar la vida. Puede de considerarse nivel de clula. 5. Quinto nivel, gentico-social. Est caracterizado por las plantas. 6. Sexto nivel, sistema animal. Se caracteriza por su creciente movilidad, comportamiento teleolgico y su autoconciencia.
15
7. Sptimo nivel, sistema humano. Es el nivel del ser individual, considerado como un sistema con conciencia y habilidad para utilizar el lenguaje y smbolos. 8. Octavo nivel, sistema social o sistema de organizaciones humanas constituye el siguiente nivel, y considera el contenido y significado de mensajes, la naturaleza y dimensiones del sistema de valores, la trascripcin de imgenes en registros histricos, sutiles simbolizaciones artsticas, msica, poesa y la compleja gama de emociones humanas. 9. Noveno nivel, sistemas trascendentales. Completan los niveles de clasificacin: estos son los ltimos y absolutos, los ineludibles y desconocidos, los cuales tambin presentan estructuras sistemticas e interrelaciones. Teora analgica o modelo de isomorfismo sistmico: Este modelo busca integrar las relaciones entre fenmenos de las distintas ciencias. La deteccin de estos fenmenos permite el armado de modelos de aplicacin para distintas reas de las ciencias. Esto, que se repite en forma permanente, exige un anlisis iterativo que responde a la idea de modularidad que la teora de los sistemas desarrolla en sus contenidos. Se pretende por comparaciones sucesivas, una aproximacin metodolgica, a la vez que facilitar la identificacin de los elementos equivalentes o comunes, y permitir una correspondencia biunvoca entre las distintas ciencias. Como evidencia de que existen propiedades generales entre distintos sistemas, se identifican y extraen sus similitudes estructurales. Estos elementos son la esencia de la aplicacin del modelo de isomorfismo, es decir, la correspondencia entre principios que rigen el comportamiento de objetos que, si bien intrnsecamente son diferentes, en algunos aspectos registran efectos que pueden necesitar un mismo procedimiento. Modelo procesal o del sistema adaptativo complejo: Este modelo implica por asociacin la aplicacin previa del modelo del rango. Dado que las organizaciones se encuentran dentro del nivel 8, critica y logra la demolicin de los modelos existentes tanto dentro de la sociologa como dentro de la administracin. Buckley, categoriza a los modelos existentes en dos tipos: a) aquellos de extraccin y origen mecnico, a los que denomina modelo de equilibrio; b) aquellos de extraccin y origen biolgico, a los que llama modelos organsmicos u homeostticos. Y dice: "...el modelo de equilibrio es aplicable a tipos de sistemas que se caracterizan por perder organizacin al desplazarse hacia un punto de equilibrio y con posterioridad tienden a mantener ese nivel mnimo dentro de perturbaciones relativamente estrechas. Los modelos homeostticos son aplicables a sistemas que tienden a mantener un nivel de organizacin dado relativamente elevado a pesar de las tendencias constantes a disminuirlo. El modelo procesal o de sistema complejo adaptativo se aplica a los sistemas caracterizados por la elaboracin o la evolucin de la organizacin; como veremos se benefician con las perturbaciones y la variedad del medio y de hecho dependen de estas". Mientras que ciertos sistemas tienen una natural tendencia al equilibrio, los sistemas del nivel 8 se caracterizan por sus propiedades morfognicas, es decir que en lugar de buscar un equilibrio estable tienden a una permanente transformacin estructural. Este proceso de transformacin estructural permanente, constituye el pre-requisito para que los sistemas de nivel 8 se conserven en forma activa y eficiente, en suma es su razn de supervivencia. LAS ORGANIZACIONES COMO SISTEMAS Una organizacin es un sistema socio-tcnico incluido en otro ms amplio que es la sociedad con la que interacta
16
influyndose mutuamente. Tambin puede ser definida como un sistema social, integrado por individuos y grupos de trabajo que responden a una determinada estructura y dentro de un contexto al que controla parcialmente, desarrollan actividades aplicando recursos en pos de ciertos valores comunes. Subsistemas que forman la Empresa: a) Subsistema psicosocial: est compuesto por individuos y grupos en interaccin. Dicho subsistema est formado por la conducta individual y la motivacin, las relaciones del status y del papel, dinmica de grupos y los sistemas de influencia. b) Subsistema tcnico: se refiere a los conocimientos necesarios para el desarrollo de tareas, incluyendo las tcnicas usadas para la transformacin de insumos en productos. c) Subsistema administrativo: relaciona a la organizacin con su medio y establece los objetivos, desarrolla planes de integracin, estrategia y operacin, mediante el diseo de la estructura y el establecimiento de los procesos de control. METODOLOGIA DE APLICACION DE LA T.G.S., PARA EL ANALISIS Y DISEO DE SISTEMAS Desde el punto de vista de la administracin est compuesta de las siguientes etapas: Anlisis de situacin: es la etapa en que el analista toma conocimiento del sistema, se ubica en cuanto a su origen, objetivo y trayectoria. 1. Definicin de objetivo: el analista trata de determinar para que ha sido requerido ya que en general se le plantean los efectos pero no las causas. 2. Formulacin del plan de trabajo: el analista fija los lmites de inters del estudio a realizar, la metodologa a seguir, los recursos materiales y humanos que necesitar, el tiempo que insumir el trabajo y el costo del mismo. Esta etapa se conoce como propuesta de servicio y a partir de su aprobacin se contina con la metodologa. 3. Relevamiento: el analista recopila toda la informacin referida al sistema en estudio, como as tambin toda la informacin que hace al lmite de inters. 4. Diagnstico: el analista mide la eficacia y la eficiencia del sistema en estudio. Eficacia es cuando el sistema logra los objetivos y eficiencia es cuando el sistema logra los objetivos con una relacin costo beneficio positiva. Si un sistema es eficaz pero no eficiente el analista deber cambiar los mtodos del sistema, si un sistema no es eficaz el analista deber cambiar el sistema y si un sistema es eficiente el analista slo podr optimizarlo. 5. Diseo: el analista disea el nuevo sistema. a) Diseo global: en el determina la salida, los archivos, las entradas del sistema, hace un clculo de costos y enumera los procedimientos. El diseo global debe ser presentado para su aprobacin, aprobado el diseo global pasamos al siguiente paso. b) Diseo detallado: el analista desarrolla en detalle la totalidad de los procedimientos enumerados en el diseo global y formula la estructura de organizacin la cual se aplicara sobre dichos procedimientos. 6. Implementacin: la implementacin del sistema diseado significa llevar a la prctica al mismo, esta puesta en marcha puede hacerse de tres formas. a) Global. b) En fases. c) En paralelo.
17
7. Seguimiento y control: El analista debe verificar los resultados del sistema implementado y aplicar las acciones correctivas que considere necesarias para ajustar el problema. EL SISTEMA DE CONTROL Concepto: Un sistema de control estudia la conducta del sistema con el fin de regularla de un modo conveniente para su supervivencia. Una de sus caractersticas es que sus elementos deben ser lo suficientemente sensitivas y rpidas como para satisfacer los requisitos para cada funcin del control. Elementos bsicos: a) Una variable; que es el elemento que se desea controlar. b) Los mecanismos sensores que son sencillos para medir las variaciones a los cambios de la variable. c) Los medios motores a travs de los cuales se pueden desarrollar las acciones correctivas. d) Fuente de energa, que entrega la energa necesaria para cualquier tipo de actividad. e) La retroalimentacin que a travs de la comunicacin del estado de la variable por los sensores, se logra llevar a cabo las acciones correctivas. Mtodo de control: Es una alternativa para reducir la cantidad de informacin recibida por quienes toman decisiones, sin dejar de aumentar su contenido informativo. Las tres formas bsicas de implementar el mtodo de control son: 1.- Reporte de variacin: esta forma de variacin requiere que los datos que representan los hechos reales sean comparados con otros que representan los hechos planeados, con el fin de determinar la diferencia. La variacin se controla luego con el valor de control, para determinar si el hecho se debe o no informar. El resultado del procedimiento, es que nicamente se informa a quin toma las decisiones acerca de los eventos o actividades que se apartan de modo significativo que los planes, para que tomen las medidas necesarias. 2.- Decisiones Programadas: otra aplicacin de sistema de control implica el desarrollo y la implantacin de decisiones programadas. Una parte apreciable de las decisiones de carcter tcnico y una parte pequea de las decisiones tcticas abarcan decisiones repetitivas y rutinarias. Diseando el sistema de informacin de manera que ejecute esas decisiones de rutina, el analista proporciona a los administradores ms tiempo para dedicarse a otras decisiones menos estructuradas. Si se procura que el sistema vigile las rdenes pendientes y se programa las decisiones de cules pedidos necesitan mayor atencin, se lograr un significativo ahorro de tiempo y esfuerzo. 3.- Notificacin automtica: en este caso, el sistema como tal, no toma decisiones pero como vigila el flujo general de informacin puede proporcionar datos, cuando sea preciso y en el momento determinado. Las notificaciones automticas se hacen en algunos criterios predeterminados, pero solo quienes toman las decisiones deben decir si es necesario o no emprender alguna accin. El Sistema de Control en las Organizaciones: El control es uno de los cinco subsistemas corporativos (organizacin, planificacin, coordinacin y direccin son los restante) los cuales son muy difciles de separar con respecto al de control. De ello se desprende todo el proceso administrativo, debe considerarse como un movimiento circular, en el cual todos los subsistemas estn ligados intrincadamente, la relacin entre la planificacin y el control es muy estrecha ya que el directivo fija el objetivo y adems
18
normas, ante las cuales se contrastan y evalan acciones. Es necesario ver al control para determinar si las asignaciones y las relaciones en la organizacin estn siendo cumplimentadas tal como se las haba previsto.
Este grfico representa el proceso de control como un sistema cerrado, es decir que posee la caracterstica de la retroalimentacin o autorregulacin. El movimiento es circular y continuo, producindose de la siguiente manera: se parte de la actividad o realidad a la cual debemos medir, con el auxilio o utilizacin de normas, efectuada la decisin comparamos los resultados de los planes, de esta manera la realidad quedar ajustada para el futuro. Se nota en este punto que no slo la realidad puede ser ajustada, otras veces son los planes los que necesitan correccin por estar sensiblemente alejado de las actividades. Cuestionario: 1. 2. 3. 4. 5. Qu Es el enfoque sistmico? Qu es la TGS? Quin fue el creador de la TGS? Qu predica la TGS? Cules son los aportes metodolgicos de la TGS? Cul es la clasificacin de los sistemas segn niveles jerrquicos? Cules son los aportes semnticos de la TGS? Qu es la Homeostacia? Qu es la Entropa? A qu se refiere el sistema de control?
6.
7. 8. 9. 10.
WORK PAPER # 2
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
19
No. DE HOJAS: 6
CDIGO: CMP 316
TTULO DEL WORK PAPER: El Ciclo de Vida y Paradigmas del desarrollo de sistemas
DPTO.: Facultad de Ingeniera UDABOL ORURO DESTINADO A: DOCENTES ALUMNOS X ADMINIST. OTROS
OBSERVACIONES: Asignatura Anlisis de Sistemas I, Carrera Ingeniera de Sistemas, Unidad I, Tema 2
FECHA DE DIFUSIN: Marzo 2011
FECHA DE ENTREGA: Marzo 2011
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
20
CICLO DE VIDA DEL DESARROLLO DE SISTEMAS Concepto de Ciclo de Vida Se aplica el trmino de ciclo de vida en las ciencias naturales, especialmente en la biologa en la que se refiere a las diferentes etapas que recorre un ser vivo durante su vida. Aunque tambin se aplica este trmino en la geologa como puede ser el ciclo de vida del agua (desde que es evaporada en el mar hasta que vuelve a l) o el ciclo de vida de las rocas (gneas, sedimentarias y metamrficas). Este trmino tambin se puede aplicar al mundo empresarial y ms concretamente al marketing, que distingue el ciclo de vida de los productos (crecimiento, madurez y senectud). En la ingeniera informtica el trmino de ciclo de vida viene citado intrnsecamente en la definicin de la ingeniera del software que tiene como objeto el proceso de desarrollo de aplicaciones informticas. Este proceso comprende la definicin de requisitos, la especificacin funcional, la descripcin del diseo, la realizacin de los programas, los mtodos de prueba, y el mantenimiento. Es decir, este proceso comprende el ciclo de vida. Sobre el ciclo de vida en la ingeniera del software IEEE e ISO/IEC han publicado normas al respecto. Las normas IEEE 1074 e ISO 12207-1 enfocan el trmino de forma muy similar considerando una actividad como un conjunto de tareas y una tarea como una accin que transforman entradas en salidas. El Ciclo de Vida en el Software Etapas generales del Ciclo de Vida
Para poder llevar a cabo la construccin de una aplicacin informtica, antes de plantearnos cmo vamos a hacer las cosas nos tendremos que plantear el problema en s y qu es lo que hay que hacer. Es decir, como en cualquier otra rama de la ingeniera tenemos que aplicar los pasos para resolver un problema : Formular el problema. Buscar y desarrollar soluciones. Evaluar las distintas soluciones en funcin de los objetivos. Refinar y verificar la solucin escogida.
Aplicacin del Ciclo de Vida al Software El ciclo de vida de una aplicacin informtica nos va a llevar desde la definicin de los requisitos hasta la finalizacin de su uso, y esto lo podemos dividir en las siguientes etapas generales:
Primer etapa : Definicin de requisitos o En esta etapa el problema principal se centra en la formulacin correcta del problema en cuestin. Resulta imprescindible conocer el problema en profundidad para poder construir la aplicacin; igualmente el desarrollo de aplicaciones de informacin para la empresa ser imprescindible estudiar las necesidades de informacin de la estructura empresarial en su conjunto. Segunda etapa : Especificacin funcional o En esta etapa se trata de expresar la estructura de la solucin, centrndonos en las necesidades del usuario de tal forma que ste pueda comprender de la forma ms correcta posible sus necesidades. En esta etapa nos aseguramos de haber entendido las necesidades del usuario. Tercera etapa : Diseo o En esta etapa el ingeniero basndose en la tcnica existente redacta los documentos que tendrn como destinatario al programador. En esta etapa se ha de expresar el problema y la solucin en trminos informticos para que el programador pueda realizar su trabajo. Cuarta etapa : Realizacin
21
FACULTAD DE CIENCIAS Y TECNOLOGIA o En esta etapa se generan los programas que componen la aplicacin. Quinta etapa: Prueba - En esta etapa se comprueba que todos los componentes de la aplicacin funcionan correctamente juntos. Sexta etapa : Mantenimiento o Con la utilizacin de la aplicacin se van descubriendo funcionamientos defectuosos, ya que el cdigo libre de error al 100% es prcticamente imposible de conseguir, o ausencia de funcionalidad que no haba sido descrita con anterioridad. En el mantenimiento se suele volver a iniciar las etapas del ciclo de vida.
El ciclo de vida se apoya en la teora de subdividir un problema en problemas ms pequeos como nos dice la teora del divide y vencers o la programacin estructurada. Planificacin del Ciclo de Vida El modelo del ciclo de vida escogido es un factor principal para conseguir los objetivos buscados, una mala eleccin del modelo de ciclo de vida puede hacer que se nos retrase el trabajo enormemente o que tengamos una planificacin perfecta del trabajo. TIPOS DE MODELOS

Cascada pura Codificar y corregir Espiral Cascadas modificadas Prototipo evolutivo Entrega por etapas Diseo por planificacin Entrega evolutiva Diseo por herramientas
1. Cascada Pura Es el ms antiguo de todos los modelos de ciclo de vida y sirve de modelo para otros modelos de ciclos de vida. En un modelo en cascada un proyecto progresa a travs de una secuencia ordenada de pasos que son: Concepto del software.

Anlisis de requerimientos. Diseo global. Diseo detallado. Codificacin y depuracin. Prueba del sistema.
El modelo contiene una serie de etapas que no se solapan, y el proyecto se va revisando tras cada una de las etapas. Para poder pasar a la siguiente etapa se tiene que haber conseguido todos los objetivos de la etapa anterior, es un proceso secuencial. Tiene una buena aplicacin cuando el problema es estable y cuando se trabaja con metodologas tcnicas conocidas. Este modelo ser apropiado para la migracin de una aplicacin o a una versin de mantenimiento bien definida. Con este modelo se tiene un seguimiento de todas las fases del proyecto y del cumplimiento de todos los objetivos marcados en cada etapa tanto de costos, fechas de entrega y lo ms importante que pueden comprobar al final de cada etapa si el proyecto cumple todas las necesidades del usuario. A su vez esto es un problema ya que si el usuario se da cuenta de que falta una tarea de la empresa en el proyecto una vez pasada esta etapa, el trabajo que hay que realizar se retrasa en fechas de entrega y el costo es mayor. Por lo tanto esto
22
produce un fracaso en la industria ya que es reacio a las modificaciones de ltima hora. Por este motivo se puede modificar el modelo en cascada pudiendo pasar de una etapa a la anterior, pero suele ser difcil ya que hay que rehacer la etapa anterior, este modelo es el ciclo de vida del salmn. Por lo tanto este es un modelo poco apropiado para proyectos con fecha de entrega corta, pero su rendimiento puede mejorar notablemente variando el modelo de la cascada pura. Variaciones sobre el Ciclo de Vida en Cascada El Ciclo de Vida en Cascada puede sufrir una serie de modificaciones para aumentar su eficiencia. Una de estas variaciones puede ser El Sashimi o Cascada con fases solapadas, en el que para evitar algunos inconvenientes del modelo en cascada solapando sus etapas, pero este enfoque genera nuevos problemas ya que debido al solapamiento los hitos resultan ms ambiguos y esto hace ms difcil trazar el proceso correctamente. Otra variacin sobre el Ciclo de Vida en Cascada sera el Ciclo de vida en cascada con Subproyectos, en el que se permite la ejecucin de algunas de las tareas de la cascada en paralelo, pero esta modificacin tiene el problema que la planificacin tiene que ser mucho ms cuidadosa, aunque se gana velocidad. 2. Codificar y Corregir El modelo codificar y corregir es el modelo utilizado cuando no nos paramos en buscar el modelo ms idneo para nuestro proyecto. Es decir en este modelo no se pierde el tiempo en la planificacin, en la calidad, en los documentos que hay que realizar cuando se terminan etapas o en cualquier otra actividad que no sea la codificacin. Por lo tanto este modelo no se necesita tener experiencia y una gran cantidad de conocimientos. Al no seguir un modelo no tenemos ningn medio de ver si se cumplen las expectativas creadas, lo cual es un problema si encontramos un error casi al finalizar el proyecto ya que hay que empezar de nuevo. Por consiguiente tardamos ms en ver los errores que en otro modelo que sigue un mnimo de planificacin. 3. Espiral El modelo de la espiral es un modelo orientado a riesgo que divide el proyecto de software en miniproyectos. Cada proyecto se encargar de resolver uno o varios riesgos hasta que estn todos controlados. Una vez que estn los riesgos ms importantes controlados se finaliza igual que el ciclo de vida en cascada. En el ciclo de vida en espiral localizan los riesgos, genera un plan para manejarlos y se establece una aproximacin a la siguiente iteracin. Con cada iteracin se produce una aproximacin al producto final. En el modelo en espiral se comienza con una parte pequea del proyecto y se expande tras reducir los riesgos para la siguiente iteracin. En cada iteracin seguimos los siguientes pasos:

Determinar objetivos, alternativas y lmites. Identificar y resolver riesgos. Evaluar las alternativas. Generar entregas de esta iteracin, y comprobar que son correctas. Planificar la siguiente iteracin. Si se decide ejecutar la siguiente iteracin, hay que establecer un enfoque para ella.
En este modelo las primeras iteraciones son menos costosas y a medida que se avanza aumenta el costo. Las ventajas de este modelo son:

Se disminuyen los riesgos. Al final de cada iteracin se obtienen los puntos de verificacin. Se obtienen con anterioridad indicaciones de cualquier riesgo insuperable.
Las desventajas de este modelo son :
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
23
Un aumento de costos. Es un modelo complicado de llevar a cabo porque exige una gestin concienzuda, atenta y unos conocimientos profundos.
4. Prototipo Evolutivo Con el prototipo evolutivo se comienza diseando y construyendo las partes ms importantes de la aplicacin en un prototipo que posteriormente se refinar y ampliar hasta que el prototipo se termine. Este prototipo ser el software que se entregar al final. Se utiliza cuando los requerimientos cambian con celeridad, cuando el cliente es contrario a facilitar los requerimientos y especificaciones o cuando no est clara la forma del rea de aplicacin. Las ventajas de este prototipo son:

Se generan signos visibles de progreso. Permite la modificacin sobre la marcha. El cliente se va familiarizando con el nuevo entorno.
Y las desventajas de este prototipo son:

Imposibilidad de conocer a priori el tiempo de desarrollo. La aproximacin puede convertirse en excusa para realizar el desarrollo con el modelo de codificar y corregir.
5. Entrega por etapas En este modelo se evita el problema del modelo en cascada de no terminar ninguna etapa del modelo hasta que este completamente finalizado. Tras el diseo global se puede implementar y entregar la aplicacin en etapas. La diferencia de este modelo con el prototipo evolutivo es que en este modelo conocemos exactamente que es lo que se va a construir. Este modelo funciona exactamente igual que el de cascada en las tres primeras fases y en el diseo detallado se divide por etapas. Sus principales ventajas son:

Permite proporcionar una funcionalidad til en manos del cliente sin tener la aplicacin finalizada. Proporciona signos tangibles de progreso.
Su principal inconveniente es que este modelo no es viable sin una planificacin adecuada. 6. Diseo por planificacin Es similar al modelo de entrega por etapas y es til cuando el proyecto tiene un plazo concreto. Este modelo se utiliza cuando no se conoce si el producto se tendr para la ltima entrega. A diferencia del modelo de entrega por etapas, estas estn ordenadas por orden de prioridad, as que la fecha tope aunque no hayamos terminado el proyecto estaremos seguros de haber cubierto las funcionalidades ms importantes. 7. Entrega evolutiva El modelo de entrega evolutiva ofrece el control que se obtiene con la entrega por etapas y la flexibilidad que se obtiene con el prototipo evolutivo. Este modelo puede ajustarse para proporcionar el control y la flexibilidad que se necesita. Este modelo realmente se encuentra entre el prototipo evolutivo y la entrega por etapas ya que se van desarrollando versiones aadiendo funcionalidad a las anteriores y se le van mostrando al cliente. Este proceso se repetir hasta agotar el tiempo, el presupuesto o hasta que el cliente este satisfecho. Para poder empezar a desarrollar versiones deberemos haber diseado el ncleo del sistema y su globalidad. Este modelo se diferencia del prototipo evolutivo en el nfasis, no en la aproximacin fundamental. En la entrega evolutiva
24
se enfatiza en el ncleo del sistema que probablemente no ser modificado por la realimentacin del cliente. Cuestionario: 1. Cules son las fases del ciclo de vida de un sistema de informacin? 2. Desarrollar un cuadro sinptico relativo a los diferentes modelos de desarrollo de sistemas. 3. Ejemplifique el ciclo de vida de desarrollo de SW para la administracin de la Biblioteca.
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
25
WORK PAPER # 3
No. DE HOJAS: 8
ELABOR: Ing. Reynaldo Einar Zabaleta Rioja TTULO DEL WORK PAPER: DIAGRAMAS DE ESTRUCTURA
CDIGO: CMP 316
DPTO.: Facultad de Ingeniera UDABOL-ORURO DESTINADO A: DOCENTES OBSERVACIONES: ALUMNOS X ADMINIST. OTROS
FECHA DE DIFUSIN: Abril 2011
FECHA DE ENTREGA: Abril 2011
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
26
DIAGRAMAS DE ESTRUCTURA INTRODUCCIN. Antes de pasar a introducirnos en los conceptos necesarios para la construccin de Diagramas de Estructura, necesitaremos aclarar lo siguiente: En que parte del proyecto estamos? A estas alturas estamos en la etapa del Diseo Estructurado; hasta aqu habamos estado trabajando en el Anlisis Estructurado, recordemos un poco: El Anlisis Estructurado. Dirigido a la primer etapa del proceso de desarrollo. Se basa en construir un modelo de las prcticas administrativas que deben ser realizadas por el nuevo sistema (desde el punto de vista lgico). Es crtica en esta fase la determinacin y la definicin de requerimientos ya que el fracaso de las especificaciones rompen todo el esfuerzo de desarrollo. Se busca conocer y especificar lo que se quiere. Si no se sabe lo que se desea no se puede esperar xito. Las salidas (output) del anlisis estructurado son (especificaciones estructuradas): Diagrama de Flujo de Datos Nivelado (DFD) o Modelo Lgico del Sistema. Permite identificar los mini sistemas y las interfaces entre ellos. Diccionario de Datos correspondiente al DFD. Define la composicin y organizacin de las interfaces. Mini Especificaciones de los Procesos (Primitivas Funcionales) que aparecen en el DFD. Se realizan a travs de ingles, castellano estructurado, arboles de decisin o tablas de decisin. EL DISEO ESTRUCTURADO. Una vez conocido Que? (Anlisis Estructurado), el Diseo Estructurado se encarga del Cmo?. Vale decir, como implementar mejor el modelo en trminos del costo total de por vida del sistema (Desarrollo y Mantencin). El diseo estructurado busca establecer la organizacin interna del software, produciendo sistemas que sean fciles de entender (y por ende de construir y mantener). Las salidas del anlisis estructurado son entradas (input) para el diseo estructurado. Las salidas (output) del diseo estructurado son: Diagrama Estructurado (estructura de software). Especificacin de Mdulos. Diccionario de Datos del Sistema. Construyendo el Modelo Fsico (Software). En la representacin grfica vemos que est compuesto de: Identificar los lmites hombre- mquina en el modelo lgico. Determinar "Frontera Hombre- Mquina". Evaluar los costos- beneficios de la solucin. Es necesario identificar el alcance del esfuerzo de desarrollo en computadora. Seleccionar opcin de entre las alternativas. En esta etapa considere las restricciones fsicas generales: Requerimientos del medio ambiente (por ejemplo gobierno). Limitaciones tecnolgicas (hardware, software, etc.).
27
Recursos Humanos. Eleccin de una implementacin (o alternativa de Mecanizacin). Decisiones sobre implementacin. Qu ser automatizado? Qu estar on- line? Qu ser distribuido? Qu ser implementado primero? Restricciones Fsicas. Computadora?. Cunto dinero se puede gastar?. Cunto se puede esperar?. Cuntos datos estn involucrados?. Cuan crtico es el tiempo de respuesta?. NUEVO MODELO LGICO.
Como hacer la Parte Automatizada ms Fsica. Dibuje el lmite de automatizacin en el nuevo modelo lgico considerando las restricciones fsicas. Adapte el modelo para mostrar explcitamente funciones divididas a lo largo del lmite de automatizacin. Redisee los modelos (DFDs) para la nueva figura0 ubicando las funciones como lo requiere el lmite de automatizacin. Agregue componentes para transportar datos a travs del lmite de automatizacin (agregue componentes transportistas). Fiscalice las mini- especificaciones. Fiscalice el diccionario.
28
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
29
DIAGRAMA DE ESTRUCTURA. Estos diagramas muestran tanto jerarqua funcional como las interfaces de los datos entre los componentes. Los principales componentes son: El rectngulo. Las flechas. El rectngulo en un diagrama de estructura no representa una declaracin sino que representa un mdulo, por ejemplo un procedimiento de Pascal. Las flechas que conectan los mdulos no representan declaraciones GOTO sino llamados de subrutinas; la notacin implica que una sub- rutina terminar o regresar a donde se llam cuando termine de realizar su funcin. Adems, existen aqu dos tipos adicionales de flechas con un crculo en uno de sus extremos, que representan la transferencia de datos y la transferencia de informacin de control.
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
30
Los mdulos dan una idea clara y sinttica de la funcin que realiza. La lectura de los diagramas de estructura se realiza de izquierda a derecha y de arriba hacia abajo. Dependiendo de la herramienta que estemos utilizando para el diseo, se nos permitirn utilizar una u otra simbologa; aqu se presentan smbolos que podramos llamarlos estndar de modelado que se agregan a los anteriores.
Cada Diagrama de Estructura, representa una burbuja del DFD. Por lo tanto es necesario que antes de pasar a confeccionar el diagrama tengamos en cuenta las siguientes consideraciones. La confeccin del diagrama de estructura debe confeccionarse luego de haber realizado el modelamiento explicado en la parte introductoria de este capitulo, lo que implica revisin, anlisis y confeccin de los diagramas ya terminados en la etapa de anlisis. Tenga en cuenta que la lgica de cada diseador se expresa en la confeccin del diagrama de estructura, por lo tanto irn desde lo ms secuenciales hasta los ms estructurados; por lo tanto no puedo decir que hay normas estrictas que indican una nica forma de realizarse lo importante es que lo mismos sean claros, consistentes y nos representen realmente las rutas que seguir luego nuestro cdigo del sistema mismo. De esta manera podr ser entendido por nuestro cliente, aunque este no querr verlo, pero si debe ser entendido por otro colega nuestro si fuera necesario; al igual que un plano puede ser comprendido por otro arquitecto, esa es la idea. Seguidamente les presento dos ejemplos de diagrama de estructura, el primero representa la pantalla principal del sistema con su men principal, el segundo es el diagrama de una opcin de men. Tengamos en cuenta que en el modela do cada opcin de nuestro sistema es conocida como pgina. Ejemplos de diagramas de modelado de un Sistema: En el primer caso un diagrama principal refirindose a cada opcin del sistema como pagina. En el segundo caso un diagrama principal refirindose a cada opcin del sistema de manera mas especifica. El tercer diagrama especifica una opcin completa del sistema.
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
31
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
32
Cuestionario:. 1. 2. 3. 4. 5. 6. Que son las herramientas de modelado de Sistemas? Porque los diagramas de estructuras sern herramientas de modelado? Explicar los Diagramas de Flujo de Datos Modelo Lgico del Sistema Explicar el Diccionario de Datos correspondiente al DFD Explicar las Mini Especificaciones de los Procesos Realizar un ejemplo de la vida real Utilizando estas herramientas.
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
33
WORK PAPER # 4
No. DE HOJAS: 4
ELABOR: Ing. Reynaldo Einar Zabaleta Rioja
CDIGO: CMP 316
TTULO DEL WORK PAPER: DETERMINACION DE REQUERIMIENTOS Y ANALISIS DE INFORMACIN
FECHA DE DIFUSIN: Abril 2011
FECHA DE ENTREGA: Abril 2011
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
34
DETERMINACIN DE REQUERIMIENTOS Y ANLISIS DE INFORMACIN REQUERIMIENTOS DE LAS TRANSACCIONES DE LOS USUARIOS Los sistemas a nivel de transacciones, capturan, procesan datos por alguna razn por ejemplo: en un sistema de pedidos los clientes son procesados de forma tal que sean artculos indicados. Los analistas seleccionados para trabajar en un sistema de pedidos deben conocer todo lo relacionado cundo procesan estas transacciones. Requerimiento de decisin de los usuarios. A diferencia de las actividades de transaccin las relacionadas con decisiones no siguen un procedimiento especifico las rutinas son muy claras y es posible que los controles vagos. Es probable que los sistemas de decisin tengan que ver con el pasado, presente o el futuro. Algunos brindan su porte para decisiones recurrentes mientras que otros son nicos y no recurrentes, estos sistemas pueden utilizar datos que se originan dentro de empresas como los generados por el procesamiento de transacciones fuera de ella, por ejemplo asociaciones o fuentes comerciales en algunos casos se procesan los datos de transaccin para generar nueva informacin para la toma de decisiones. Requerimiento de toda la organizacin. En las empresas los departamentos dependen de uno de ot4ro para brindar servicios para fabricar productos y satisfacer a los clientes. Por consiguiente el trabajo hecho en un depto afecta al de los otros. Cuando los analistas estudian sistemas para un departamento tambin deben evaluar las implicaciones. Algunas veces los sistemas abarcan los trabajos de varios deptos. La recepcin del pedido ilustra la importancia de considerar las ramificaciones de un tipo de actividad para l resto de las organizaciones. Cuando el grupo de ventas toma un pedido la accin da origen a una serie de actividades que afectan a las dems reas. Es probable que los analistas que tiene inters en el proceso de recepcin de pedidos no trabaje al mismo tiempo sobre el sistema de facturacin, sin embargo deben tener conocimientos de cualquier requerimiento en cualquier otra parte de la organizacin, si el proceso de recepcin de pedidos no captura la direccin de los clientes para el cobro o el lugar donde deben enviar los productos entonces cmo enviar los artculos o las facturas por correo a su lugar de destino? Entonces es importante estar al tanto de otros requerimientos de la organizacin. Anlisis estructurado Permite al analista conocer un sistema o proceso (actividad) en una forma lgica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningn detalle pertinente". El objetivo que persigue el anlisis estructurado es organizar las tareas asociadas con la determinacin de requerimientos para obtener la comprensin completa y exacta de una situacin dada. Componentes: Smbolos grficos: sirven para identificar y describir los componentes de un sistema y las relaciones entre estos. Diccionarios de datos: Descripciones de todos los datos utilizados en el sistema pueden ser manual o automatizado. Descripciones de procesos y procedimientos: emplean tcnicas y lenguajes que permiten describir actividades del sistema.
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
35
Reglas: Estndares par describir y documentar el sistema en forma correcta y completa. Anlisis de flujo de datos: Estudia el empleo de los datos en cada actividad, documenta los hallazgos con diagramas de flujo de datos. Herramientas: Diagrama de flujo de datos: son la herramienta mas importante y la base en donde se desarrolla otros componentes. Diccionario de datos: contienen las caractersticas lgicas de los lugares donde se almacenan los datos del sistema, incluyendo nombre, alias, descripcin, contenido y organizacin. Diagrama de estructuras de datos: este es una descripcin de la relacin entre entidades (personas, lugares, eventos y objetos ) y el conjunto de informacin relacionado con la entidad. Grfica de estructura: es la herramienta del diseo que muestra con smbolos la relacin entre los mdulos de procesamiento y el software de la comp. Prototipos De Aplicaciones El termino prototipo se refiere a un modelo que funciona por una aplicacin de sistemas de informacin. Caractersticas Usos El prototipo es una aplicacin que funciona La finalidad del prototipo es probar varias suposiciones formuladas por analistas o usuarios. Los prototipos se crean con rapidez Los prototipos evolucionan a travs de procesos interactivos. Tienen un costo bajo de desarrollo.
1. Es un medio eficaz para aclarar los requerimientos de los usuarios y debe satisfacer una aplicacin. 2. Verificar la factibilidad del diseo de un sistema Herramientas De Los Prototipos. El empleo de herramientas adecuadas es un factor muy importante para el xito del prototipo. Lenguajes de cuarta generacin: Los lenguajes de cuarta generacin fueron creados par ayudar a satisfacer la necesidad de desarrollar software con mayor eficiencia. Lenguajes no orientados hacia procedimientos: algunas veces el lenguaje recibe el nombre de lenguajes no precedulares. Un solo mandato lleva acabo una funcin completa. Lenguajes de consulta y recuperacin: facilitan la recuperacin de datos almacenados sin necesidad de escribir muchas instrucciones orientada hacia procedimientos. Generadores de reportes: permiten a los usuarios obtener con facilidad datos de archivos o bases de datos. Generadores de aplicaciones. Generadores de pantalla: es una herramienta interactiva para dibujar pantallas y efectuar la validacin automtica de la entrada y procesamientos. Sistema de diccionario de datos: guardan definiciones y descripciones de los datos utilizados en los sistemas de informacin
36
de la organizacin. Computadoras personales: el prototipo se puede crear sobre una maquina diferente, tal como una computadora personal para verificar el diseo del sistema. Estrategias Estrategias par el desarrollo de prototipos. Se puede desarrollar un prototipo para cada uno de los diferentes componentes de una aplicacin. Es comn el uso de tres estrategias para el desarrollo de prototipos de aplicaciones. Prototipo para pantalla: los prototipos de pantalla de visualizacin permiten a los usuarios y analistas evaluar la posicin de la informacin sobre la pantalla, la conveniencia de los encabezados y la utilidad de mensajes e instrucciones tambin proporcionan una manera para obtener las reacciones de los usuarios hacia la cantidad de informacin presentada sobre la pantalla de visualizacin. Prototipo para el procedimiento de procesamiento: las funciones de procesamiento incluyen entradas, clculos, recuperacin de informacin y actividades de salida. El desarrollo de prototipo para los procedimientos de procesamiento aborda solo las actividades que se preceden a la aplicacin. Prototipos para funciones bsicas: incluye mdulos que realizan muchas funciones diferentes entre las que se encuentran: Creacin de archivos maestros o bases de datos Preparacin de copias de respaldo Reorganizacin de archivos o bases de datos Seleccin y borrador de registros
Cuestionario: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Cual es la importancia de la determinacin de requerimientos? Cual es la importancia del anlisis de Informacin? Que es un requerimiento? Ejemplificar los tipos de requerimientos de la lectura del actual W.P. ? Que es el anlisis Estructurado y cuales son sus componentes? Que es un prototipo de aplicacin? Cuales son las caractersticas de un prototipo de aplicacin? Cuales son las herramientas de los prototipos? Explicar las mas Importantes. A su opinin cual es la mas importante?
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
37
WORK PAPER # 5

No. DE PROCEDIMIENTO: APRO 07 No. DE HOJAS: 9
CDIGO: CMP 316
TTULO DEL WORK PAPER: ANALISIS ESTRUCTURADO Y ORIENTADO A OBJETOS DPTO.: Facultad de Ingeniera UDABOL ORURO DESTINADO A: DOCENTES ALUMNOS X ADMINIST. OTROS
OBSERVACIONES: Asignatura Anlisis de Sistemas I, Carrera Ingeniera de Sistemas, Unidad II, Tema 3
FECHA DE DIFUSIN: Mayo 2011
FECHA DE ENTREGA: Mayo 2011
DIFERENCIAS ENTRE ANLISIS Y DISEO ESTRUCTURADO Y ORIENTADO A OBJETOS

38
Tal y como lo definiera el autor, Senn J. (1992): El aspecto fundamental del anlisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra en estudio (p.35). De acuerdo a esta definicin, la accin de adquirir informacin acerca del funcionamiento de algn sector de la organizacin, es obtener una investigacin detallada del tema objeto de estudio. Esta informacin detallada y pormenorizada del entorno en estudio, conlleva a la determinacin de ciertas condiciones o requerimientos propios de un sistema. Existen diversos mtodos y tcnicas que conducen a un modelo del sistema mucho ms ptimo y eficiente, como es el caso del Anlisis y Diseo Estructurado y el Orientado a Objetos, ambos con muchos puntos a favor y con el objetivo comn de orientar al analista el la seleccin de acciones que representen un cambio positivo a la organizacin. A pesar de la aceptacin que tienen ambas metodologas actualmente, el propsito de esta investigacin es poder compararlas y evaluarlas a fin de determinar que realmente marca la diferencia cuando se analizan y disean sistemas de informacin con el uso de estas poderosas herramientas. ENFOQUE ESTRUCTURADO VS. ENFOQUE ORIENTADO A OBJETOS En cuanto a la forma de desarrollar el anlisis las metodologas son radicalmente diferentes desde su enfoque, la primera est orientada a procesos, tomando una visin donde los datos se consideran separadamente de los procesos que los transforman, dando ms importancia a la descomposicin funcional del sistema, y por tanto a los diagramas de procesos, esto puede parecer que lleva de manera ms directa a la implementacin del sistema, pero con frecuencia ste suele ser ms frgil. Si cambian los requerimientos un sistema basado en descomposicin funcional puede requerir una reestructuracin masiva. Por el contrario el enfoque orientado a objeto se centra en primer lugar en identificar los objetos del dominio de aplicacin y despus en establecer procedimientos que los manejen. Aunque esto pueda parecer ms indirecto el software orientado a objeto se mantiene mejor ante los cambios de requerimientos porque se basa en la estructura subyacente del dominio de aplicacin en vez de los requerimientos funcionales de un determinado problema. ANLISIS Y DISEO ESTRUCTURADO (ADE) o o El Anlisis se refiere al "extremo inicial" de un proyecto de desarrollo de sistemas, durante el tiempo en que los requisitos del usuario son definidos y documentados. El Anlisis estructurado introduce el uso de las herramientas de documentacin grficas para producir un tipo diferente de especificacin funcional: "la especificacin estructurada".
Conceptos que se relacionan con el Anlisis Estructurado o o o o Smbolos grficos; iconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes. Diccionario de datos; descripciones de todos los datos utilizados en el sistema. Descripciones de procesos y procedimientos; declaraciones formales que emplean tcnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema. Reglas; estndares para describir y documentar el sistema en forma correcta y completa.
Fase de Diseo En esta fase, el diseo esctructurado produce el modelo de diseo con los siguientes elementos: o Diseo de datos. Transforma el modelo de dominio de la informacin creado durante el anlisis, en las estructuras de datos necesarias para implementar el software. Los objetos de datos y las relaciones definidas en el diagrama entidad-relacin y el contenido detallado de datos del diccionario de datos constituyen la base para el diseo de datos. o Diseo arquitectnico. Define la relacin entre los principales elementos estructurales del programa. Se obtiene a partir del modelo de anlisis y de la interaccin de subsistemas definidos dentro del modelo de anlisis.
39
Diseo de interfaz. Describe como se comunica el software consigo mismo, con los sistemas que operan con l y con los operadores que lo emplean. Los diagramas de flujo de datos y control proporcionan la informacin necesaria para el diseo de la interfaz. Diseo procedimental. Transforma elementos estructurales de la arquitectura del programa en una descripcin procedimental de los componentes del software. Se obtiene a partir de la especificacin del proceso, la especificacin del control y el diagrama de transicin de estados.
ANLISIS Y DISEO ORIENTADO A OBJETOS (ADOO) Es un mtodo de anlisis que examina los requerimientos desde la perspectiva de clase y objetos encontrada en el vocabulario original del problema. Se fundamenta en un conjunto de principios bsicos: Modelar el dominio de la informacin. Describir la funcin del mdulo. Representar el comportamiento del modelo. Dividir el modelo para mostrar ms detalles. En este tipo de anlisis los modelos iniciales representan la esencia del problema, mientras que los ltimos aportan detalles de la implementacin. Caractersticas del Anlisis Orientado a Objetos o o Identidad: Los datos estn cuantificados en entidades discretas y distinguibles denominadas objetos. Estos pueden ser tangibles o intangibles. Clasificacin: Los objetos con la misma estructura de datos (atributos) y comportamiento (operaciones) se agrupan para formar una misma clase, se dice que cada objeto es una instancia de su propia clase, y una clase es una abstraccin que describe propiedades importantes para una aplicacin y se olvida del resto. Polimorfismo: Significa que una misma operacin puede comportarse de modos distintos en distintas clases, una operacin es una accin o transformacin que se aplica a un objeto. Herencia: Comparte atributos y operaciones entre clases tomando como base una relacin jerrquica, es decir que se puede definir una clase que despus producir subclases, sabiendo que todas las subclases adquirirn todas y cada una de las propiedades de su super-clase y le agrega adems sus propiedades exclusivas.
o o
Fase de Diseo Para los sistemas orientados a objetos es posible definir un diseo en pirmide con las siguientes cuatro capas: o o Subsistema. Contiene una representacin de cada uno de los subsistemas que le permiten al software conseguir los requisitos definidos por el cliente e implementar la infraestructura tcnica que los soporta. Clases y Objetos. Contiene las jerarquas de clases que permiten crear el sistema utilizando generalizaciones y especializaciones mejor definidas incrementalmente. Tambin contiene representaciones de diseo para cada objeto. Mensajes. Contiene los detalles que permiten a cada objeto comunicarse con sus colaboradores. Establece las interfaces externas e internas para el sistema. Responsabilidades. Contiene las estructuras de datos y el diseo algortmico para todos los atributos y operaciones de cada objeto. Tabla de Diferencias
o o
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
40
Anlisis y Diseo Estructurado Se consideran los elementos o perspectivas bsicas del anlisis (Entrada-Proceso-Salida), en funcin del Software. Utiliza el diagrama estructurado como representacin grfica del sistema. Consta de 5 Fases (Anlisis, Diseo, Codificacin, Pruebas e Integracin).
Anlisis y Diseo Orientado a Objetos Se consideran los conceptos bsicos como el Objeto y el Atributo, el todo y sus partes (software), clases y miembros. Modela los objetos que son parte de l. Utiliza el diagrama orientado a objetos como representacin grfica del sistema. Consta de 4 Fases (Anlisis, Diseo, Evolucin y Modificacin). Une a los usuarios y a los diseadores. Permite No enfoca apropiadamente el diseo de familias de proporcionar una descripcin completa del problema, programas. Asume una progresin relativa uniforme legible y revisable por las partes interesadas y de pasos de elaboracin. verificable contra la realidad. Si estn correctamente definidas las jerarquas de clase, No acomoda el tipo de desarrollo evolutivo. No enfoca hacer modificaciones no es tan costoso como en el caso los posibles modos futuros de desarrollo de software. de programacin tradicional. Slo hay que entrar en la parte de Evolucin para hacer modificaciones. El Diseo inicia an antes de concluir con la etapa de El Diseo inicia una vez que ha culminado la fase de anlisis. Se recomienda analizar un poco y disear. Esta anlisis de sistema. etapa debe concluir una vez que se establecieron claves y mecanismos importantes. Un programa que se usa en un ambiente real En este anlisis se llega solo a la fase de integracin necesariamente debe cambiar. Los cambios difieren un y no toma en consideracin los cambios que ocurren poco de los requeridos en evolucin, pues contemplan dentro del sistema en el proceso de anlisis y diseo la introduccin de nuevas funcionalidades no previstas de sistemas. en el problema original. Las herramientas utilizadas son: Diagramas de Clases, Las herramientas utilizadas son: Diagrama de Flujo de Diagrama de Objetos, Diagramas de Mdulos, Datos, Diagramas de Entidad-Relacin, Diagrama de Diagramas de Procesos, Diagramas de Transicin de Transicin de Estados. Estados, Diagramas de Tiempo. El anlisis est orientado a los Procesos del sistema. El anlisis est orientado a los Objetos. Requiere traducir el dominio del problema en una Es una forma de pensar acerca de un problema en serie de funciones y subfunciones. El analista debe trminos del mundo real en vez de en trminos de un comprender primero el dominio del problema y a ordenador. El AOO permite analizar mejor el dominio del continuacin documentar las funciones y problema, sin pensar en trminos de implementar el subfunciones que debe proporcionar el sistema. No sistema en un ordenador. El AOO permite pasar existe un mecanismo para comprobar si la directamente el dominio del problema al modelo del especificacin del sistema expresa con exactitud los sistema. requisitos del sistema. Este enfoque se adapta bien al uso de sistemas El concepto OO es ms simple y est menos informticos para implementar el sistema, pero no es relacionado con la informtica que el concepto de flujo nuestra forma habitual de pensar. La comunicacin de datos. Esto permite una mejor comunicacin entre el entre el analista y la Organizacin est limitada, por analista y el experto en el dominio del problema (es las fases. decir, el cliente). La relacin entre los modelos es muy dbil, y hay muy Los objetos encapsulan tanto atributos como poca influencia de un modelo en otro. En la prctica, operaciones. Debido a esto, el AOO reduce la distancia los modelos de procesos y de datos de un mismo entre el punto de vista de los datos y el punto de vista sistema se parecen muy poco. En muchos casos son del proceso, dejando menos lugar a inconsistencias o visiones irreconciliables, no del mismo sistema, sino disparidades entre ambos modelos.
41
de dos puntos de vista totalmente diferentes de organizar la solucin. Caso Prctico. Aplicar ambos enfoques de anlisis y diseo de sistemas para tratar de optimizar el proceso de generar Copias Certificadas en el Circuito Judicial Penal El caso en estudio consiste en elaborar una propuesta para optimizar especficamente el proceso de emisin de Copias Certificadas solicitadas a diario por la comunidad ante este despacho jurdico, cabe mencionar que en la actualidad esta actividad se efecta de manera exclusivamente manual, utilizando herramientas bastante obsoletas, como las mquinas de escribir y basandose en informaciones contenidas en los registros de libros de actas que se encuentran archivados en conjunto con otro elevado nmero de libros que representan todas las competencias del ente judicial. Este procedimiento ambiguo por dems, genera prdidas de tiempo en respuesta al pblico y bsqueda y tratamiento de la informacin por parte de los funcionarios que all laboran, inclusive fatiga al tener que transcribir grandes volmenes de datos de acuerdo a lo solicitado y ms an excesivos pasos y procedimientos para completar las actividades. Segn el Modelo Estructurado El Anlisis Estructurado, fue seleccionado como tcnica de investigacin de requerimientos, ya que permite al analista conocer el sistema o proceso en una forma lgica y manejable, al mismo tiempo que proporciona la base para asegurar que no se omite ningn detalle. Este es un mtodo para el anlisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. Aunado a ello y por ser considerados como una herramienta capaz de describir y analizar el movimiento de los datos a travs de un sistema, la representacin grfica de los procesos del sistema estar a cargo de los Diagramas de Flujos de Datos (DFD). Diagrama de Flujos de Datos del Proceso Actual
Diseo del Sistema. El uso de los Diagramas de Flujos de Datos (DFDs), es una herramienta que permite mostrar grficamente y de manera general, el funcionamiento del sistema y los procesos necesarios para su desarrollo. Los DFDs se pueden dibujar con slo cuatro notaciones sencillas, en este caso, la notacin utilizada est basada en el enfoque de Gane y Sarson.
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
42
Origen/Destino de Datos: Representan entidades externas al sistema que se comunican con l y que estn fuera de su control. Las relaciones existentes entre las entidades no se representan en el DFD, ya que no son parte del sistema bajo estudio. Para este diseo forman parte de las entidades los Justiciables, la cual incluye a todas aquellas personas que tienen relacin directa con el proceso. Las entidades Secretaria, Juez y Asistente, quienes conforman al rgano jurdico y son los garantes de llevar a cabo el proceso judicial. Procesos: Muestran la parte del sistema que transforma las entradas de datos en salida; en tal sentido, el diagrama (DFD Propuesto) muestra cinco (5) procesos considerados vitales para el funcionamiento y operatividad de la aplicacin: Solicitar Copias Certificadas; en el cual se supervisa que las solicitudes a procesar estn conforme a los requisitos establecidos por el Cdigo de Procedimiento Civil, o alguna otra Ley que condicione la puesta en marcha de stas. Verificar Existencia de Actas en el Sistema; en el se constata que el acta que tiene relacin con la copia certificada solicitada est o no en los archivos del circuito y de ese modo se tenga acceso directo a el. Generar Copias Certificadas; encargado de procesar los reportes generados por el sistema, en este caso la emisin directa de las Copias Certificadas solicitadas Registro Automtico de Libros; en el se almacena una serie de datos proveniente del procesamiento de las solicitudes. Firmar y Sellar Actas: Proceso manual que se limita a autenticar las Copias Certificadas previa su entrega al solicitante Flujo de Datos: El flujo describe el movimiento de paquetes de datos que viajan desde una parte del sistema a otra. Estn representados por una flecha para mostrar su origen y su destino. Almacn: Representa una coleccin de paquetes de datos que permanecen en estado de reposo. No est referido exclusivamente a medios de almacenamiento electrnico como bases de datos en discos duros, sino tambin a archiveros metlicos o cualquier otro medio que permita guardar datos en carpetas u hojas de papel.
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
43
Diagrama de Flujos de Datos del Proceso Propuesto
Segn el Modelo Orientado a Objetos James Martn, en su libro Anlisis y diseo de un sistema, Orientado a Objetos, seala que en el mundo orientado a objetos, el anlisis se realiza al estudiar los objetos en un ambiente y los eventos que interactan con dichos objetos. Por tal razn, hace referencia que una herramienta til para la descripcin de tales eventos son los Diagramas de flujo de Objetos (DFO), porque permiten mostrar las actividades que interactan con otras en un sistema cualquiera. Los DFO a diferencia de los DFD permiten mostrar no solo la transferencia de datos, si no tambin representar cualquier cosa que se transfiera de una actividad a otra; es decir, indicar los objetos que se producen y las actividades que producen e intercambian.
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
44
Diagrama de Flujos de Objetos del Proceso Actual
Diseo del Sistema Los Diagramas de Flujo de objetos, en general describen los objetos y como se producen y se consumen. Por ello para representar los procesos de nuestro caso se emplearon las simbologas descritas por James Martin y James Odell; graficadas por medio de cuatro notaciones: Agentes Externos: Cajas sombreadas que representan en nuestro caso al Justiciable, Asistente y Secretaria. Actividades: Visualizan las actividades llevadas a cabo por los agentes externos; desde que se solicita hasta que se obtiene una Copia Certificada. Producto: Es el resultado final que satisface el propsito de la actividad. Direccin de flujo de lneas: Flechas que sealan el inicio y final del flujo de Objetos o Actividades.
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
45
Diagrama de Flujos de Objetos del Proceso Propuesto
Cuestionario: 1. A base del caso practico ilustrado indicar las analogas entre los diferentes diagramas del Anlisis Estructurado y el Anlisis Orientado a Objetos. 2. A base del caso practico ilustrado, desarrollar los modelos desde el punto de vista del anlisis estructurado para el Control de la Biblioteca.
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
46
WORK PAPER # 6
No. DE HOJAS: 6
ELABOR: Ing. Reynaldo Einar Zabaleta Rioja TTULO DEL WORK PAPER: HERRAMIENTAS DE MODELADO
CDIGO: CMP 316
FECHA DE DIFUSIN: Junio 2011
FECHA DE ENTREGA: Junio 2011
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
47
HERRAMIENTAS DE MODELADO PARA QU SE UTILIZAN LAS HERRAMIENTAS DE MODELADO? La labor del anlisis involucra el modelado del sistema que desea el usuario, hay muchos tipos diferentes de modelos que se pueden elaborar, como modelos diferentes puede hacer de una casa nueva un arquitecto. Los modelos de anlisis de sistema son representaciones abstractas de lo que al final ser una combinacin de hardware y software. El trmino 'modelo' puede parecer formal, pero representa un concepto manejado durante la mayor parte de la vida. Consideremos los siguientes tipos de modelos: Mapas, modelos bidimensionales del mundo en que vivimos. Diagrama de Flujo, representaciones esquemticas de las decisiones y la secuencia de actividades para llevar a cabo un determinado procedimiento. Dibujos Arquitectnicos, representaciones esquemticas de un edificio o un puente, etc. Podramos preguntarnos porqu se construye modelos y no simplemente el sistema mismo? La respuesta es que podemos construir modelos de manera tal que enfatizamos ciertas propiedades crticas del sistema, mientras que simultneamente desacentuamos otros de sus aspectos. Esto nos permite comunicarnos con el usuario de una manera enfocada, sin distraernos con asuntos y caractersticas ajenas al sistema. Adems, si nos damos cuenta que nuestra visin de los requerimientos no fue la correcta (o que este cambia respecto a sus requerimientos), se podrn hacer cambios en el modelo o desecharlo y hacer uno nuevo de ser necesario. La alternativa es realizar reuniones con el cliente para poder reunir toda la informacin necesaria y luego construir el sistema, corremos el riesgo de que nuestro cliente no este conforme con el producto final y los cambios a esta altura podran resultar muy costosos. Entonces utilicemos las herramientas de modelado para: Concentrarse en las propiedades importantes del sistema, y restarle atencin a las menos importantes. Discutir cambios y correcciones en los requerimientos de usuarios, a bajo costo y riesgo mnimo. Verificar que el analista comprenda correctamente el ambiente del usuario y que lo haya respaldado con informacin documental para que los diseadores de sistemas y programadores puedan construir el sistema. Herramientas de Modelado Importantes. 1. 2. 3. 4. Modelado de las Funciones del Sistema. Diagrama de Flujo de Datos. Modelado de Datos Almacenados. Diagrama de Entidad - Relacin. Modelado de las Estructuras de los Programas. El Diagrama de las Estructuras. Modelado de la Estructura de los Programas. El Diagrama de Estructura.
Modelado de las Funciones del Sistema. Diagrama de Flujo de Datos. Ilustra las funciones que el sistema debe realizar. Podra describirse como qu transformaciones debe llevar a cabo el sistema? Qu entradas se Transforman en qu salidas? Entre otras. Los diagramas de flujo de datos consisten en procesos, agregados de datos y terminadores: Los procesos se representan por medio de crculos, o 'burbujas' en el diagrama. Representan las funciones individuales que el sistema lleva a cabo. Las funciones transforman entradas en salidas. Los flujos se muestran por medio de flechas curvas, son conexiones entre los procesos y representa la informacin que dicho proceso necesita como entrada o genera como salida. Los agregados de datos se representan por medio de dos lneas paralelas o mediante una elipse. Muestran colecciones de datos que el sistema debe recordar por un perodo de tiempo. Cuando los diseadores de sistema y
48
programadores terminen de construir el sistema, estos sern archivos o bases de datos. Los terminadores muestran la entidad externa con la que el sistema se comunica, tpicamente son individuos; grupos de personas; organizaciones externas; otros sistemas, etc. Ejemplo diagrama de Flujo.
El diagrama de flujo de datos proporciona una visin global de los componentes funcionales del sistema, pero no da detalles de estos. Para mostrar detalles acerca de que informacin se transforma y como se transforma, se ocupan dos herramientas textuales de modelado adicionales: el Diccionario de Datos y la Especificacin de Procesos. Ejemplo Diccionario de Datos: NOMBRE del cliente = tratamiento de cortesa o titulo + nombre + apellido Tratamiento de cortesa o ttulo = [Sr. | Srta. | Sra. | Dr. | Prof.] Nombre = {carcter valido} Apellido = {carcter valido} Carcter valido = [A - Z| a -z| | - |] Ejemplo de Especificacin de Proceso Tpica para un solo proceso. Por cada pago de cliente ingresado Buscar su detalle de factura correspondiente al cliente Si el pago es efectivo Colocar sello de pagado a la factura del cliente Colocar marca de pagado en factura copia y almacenar En caso contrario Descontar monto pagado a factura cliente Acentar fecha de entrega. Almacenar factura cliente copia Entregar recibo entrega. Fin pago. Modelado de Datos Almacenados. Diagrama de Entidad - Relacin.
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
49
Estos diagramas hacen nfasis en las relaciones entre los datos. Todos los sistemas almacenan y usan informacin acerca del ambiente en el cual interactan; a veces, esta informacin es mnima, pero en la mayora de los sistemas es bastante compleja. No solo deseamos conocer en detalle que informacin hay en cada agregado de datos, sino que tambin queremos conocer la relacin que existe entre agregados. Este aspecto del sistema no se resalta en el diagrama de flujo, pero s aqu. Este diagrama consta de dos elementos fundamentales: Tipo de Objetos: se representan por medio de un rectngulo en los diagramas. Esto representa una coleccin o conjunto de objetos (cosas) del mundo real cuyos miembros juegan algn papel en el desarrollo del sistema; pueden adems identificarse de manera nica y ser descriptos por uno o ms atributos. Relaciones: se representan por medio de rombos en el diagrama y son la serie de conexiones o asociaciones entre los tipos de objetos que estn conectados por la relacin por medio de flechas. Ejemplo de Diagrama de Entidad Relacin.
Modelado del Comportamiento Dependiente del Tiempo. El Diagrama de Transicin de Estados. La secuencia con la cual se har el acceso a los datos y se ejecutarn las funciones es un tercer aspecto de muchos sistemas complejos. Para algunos sistemas de empresas este tema no es importante, puesto que la secuencia es trivial. As, en muchos sistemas que no son de tiempo real, ni estn en lnea, la funcin N no puede llevarse a cabo hasta que recibe la entrada que requiere; y esta entrada se produce como salida de una funcin N-1 y as sucesivamente. Muchos sistemas en lnea y de tiempo real tienen complejas relaciones en el tiempo, que deben modelarse tan cuidadosamente como las funciones y las relaciones de datos.
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
50
Ejemplo Diagrama de Transicin de Estados:
Modelado de la Estructura de los Programas. El Diagrama de Estructura. Herramienta grfica de modelado utilizada para representar la jerarqua de software. Este diagrama cada rectngulo representa un mdulo (por ejemplo un sub- programa de Cobol), las flechas que conectan los rectngulos representan invocaciones de mdulos (por ejemplo llamado de subrutinas). El diagrama tambin muestra parmetros de entrada que se le dan a cada mdulo invocado y parmetros de salida devueltos por cada mdulo cuando termina su tarea y devuelve el control al que lo llama. Este diagrama es una herramienta excelente para los diseadores de sistemas, pero no es el tipo de modelo que normalmente se mostrar al usuario, pues modela un aspecto de la implantacin del sistema, no de sus requerimientos. Ejemplo de Diagrama de Estructura:
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
51
Cuestionario: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Qu son las herramientas de Modelado? Que entiende por el Termino herramienta? Para que se utilizan las Herramientas de Modelado? Qu es un Modelo? Citar las Herramientas de Modelado mas Importantes y explicarlas Brevemente? En su criterio cual es la herramienta de modelado mas Importante, justificar la eleccin? Realizar un Ejemplo de Aplicacin de la Herramienta de Modelado Diagrama de Flujo? Realizar un Ejemplo de Aplicacin de la Herramienta de Modelado Diccionario de Datos? Realizar un Ejemplo de Aplicacin de la Herramienta de Modelado Diagrama Entidad Relacin? Realizar un Ejemplo de Aplicacin de la Herramienta de Modelado Diagrama de Estructura?
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
52
WORK PAPER # 7
No. DE HOJAS: 5
ELABOR: Ing. Reynaldo Einar Zabaleta Rioja
CDIGO: CMP 316
TTULO DEL WORK PAPER: INTRODUCCION A LOS SISTEMAS DE INFORMACION
FECHA DE DIFUSIN: Julio 2011
FECHA DE ENTREGA: Julio 2011
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
53
INTRODUCCION A LOS SISTEMAS DE INFORMACION Objetivo: Conocer los conceptos bsicos, los elementos y la clasificacin de los sistemas de informacin y su relacin con los analistas de sistemas. Introduccin: En una organizacin o empresa, el analista y diseo de sistemas es el proceso de estudiar su situacin con la finalidad de observar como trabaja y decir si es necesario realizar una mejora; el encargado de realizar estas tareas es el analista de sistemas para . Antes de comenzar el desarrollo de cualquier proyecto, se conoce un estudio de sistema s para detectar todos los detalles de la situacin actual en la empresa. La informacin reunida con este estudio sirve como base para crear varias estrategias de diseo. Los administradores deciden qu estrategia seguir. Los gerentes, empleados y otros usuarios finales que se familiarizan cada vez ms con el empleo de computadoras estn teniendo un papel muy importante en el desarrollo de sistemas. Todas las organizaciones son sistemas que actan recprocamente con su medio ambiente recibiendo entradas y produciendo salidas. Los sistemas, que pueden estar formados por otros sistemas ms pequeos denominados subsistemas, funcionan para alcanzar fines especficos. Sin embargo, los propsitos o metas se alcanzan slo cuando se mantienen el control. Sistema de Informacin: Conjunto u ordenacin de elementos organizados para llevar a cabo algn mtodos, procedimiento o control mediante el proceso de informacin. Anlisis y Sistemas: El anlisis y diseo de sistemas se refiere al proceso de examinar la situacin de una empresa con el propsito de mejorar con mtodos y procedimientos ms adecuados. El desarrollo de sistemas tiene dos componentes. Anlisis Es el proceso de clasificacin e interpretacin de hechos, diagnostico de problemas y empleo de la informacin para recomendar mejoras al sistemas. Diseo: Especifica las caractersticas del producto terminado. Anlisis: Especifica que es lo que el sistema debe hacer. Diseo: Establece como alcanzar el objetivo. Lo que no es el anlisis de sistemas NO es: El estudio de una empresa para buscar procesos ya existentes con el propsito de determinar cules deberan, ser llevados a cabo por una computadora y cules por mtodos manuales. La finalidad del anlisis est en comprender los detalles de una situacin y decir si es deseable o factible una mejora. La seleccin del mtodo, ya sea utilizando o no una computadora, es un aspecto secundario. No es: Determinar los cambios que deberan efectuarse. No es: Determinar la mejor forma de resolver un `problema de sistemas de informacin. Sin importar cul sea la organizacin, el analista trabaja en los problemas de sta. Es un error hacer una distincin entre los problemas de la empresa y los de sistemas ya que estos ltimos no existiran sin los primeros. Cualquier sugerencia debe primero considerarse a la luz de si
54
beneficiar o perjudicar a la organizacin. No se debe ir tras ideas tcnicamente atractivas a menos que estas mejoren el sistema de la organizacin. El Analista de Sistemas de Informacin En una empresa pequea, lo ms probable es que realice las actividades: 1.-ANALISIS DE SISTEMAS (Analista de informacin): Es reunir informacin y determinar los requisitos. Los analistas no son responsables del diseo de sistema. 2.-ANALISIS Y DISEO DEL SISTEMA (Diseadores de sistemas, Diseadores de aplicaciones): El analista tiene la responsabilidad adicional de disear el nuevo sistema. 3.-ANALISIS, DISEO Y PROGRAMACIN DEL SISTEMA (Analista programador): Desarrolla las especificaciones de diseo y escribe el software necesario para implementar el diseo. ELEMENTOS DE UN SISTEMA DE INFORMACION SOFWARE. Los programas de computadoras, as estructuras de datos y la documentacin asociada, que sirve para realizar el mtodo lgico. HARWARE: Los dispositivos electrnicos que proporcionan la capacidad de computacin y que proporcionan las funciones del mundo exterior. GENTE: Los individuos que son usuarios y operadores del software y del hardware. BASES DE DATOS: Una coleccin grande y organizada de informacin a la que se accede mediante el software y que es una parte integral del funcionamiento del sistema. DOCUMENTACION: Los manuales, los impresos y otra informacin descriptiva que explica el uso y / o la operacin. PROCESAMIENTOS: Los pasos que definen el uso especifico de cada elemento del sistema o el contexto procedimental en que reside el sistema. CONTROL: Los sistemas trabajan mejor cuando operan dentro de niveles de control tolerables de rendimiento por ejemplo: el sistema de control de un calentador de agua. Clasificacin de los Sistemas de Informacin Abiertos.: Son los que intercambian informacin, materiales y energa con su ambiente. Cerrados: Son auto contenidos, no interactan con el medio ambiente. Probabilstico: No se conoce con certeza su comportamiento. Deterministico:. Cualquier estado futuro que adopten puede preciarse con antelacin.
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
55
Caractersticas de Sistema de Informacin Sus principales caractersticas son: Suelen lograrse ahorros significativos de mano de obra. Son el primer tipo de sistemas de informacin que se implanta en las organizaciones. Son intensivos en entradas y salidas de informacin; sus clculos y procesos suelen ser simples y copo sofisticados, requieren mucho manejo de datos para poder realizar sus operaciones y como resultado generan tambin gr4andes volmenes de informacin. Tiene la propiedad de ser recolectores de informacin. Son adaptables de aplicacin que se encuentran en el mercado. Ejemplos: facturacin, nminas, cuentas por cobrar, cuentas por pagar, contabilidad general. SISTEMAS DE APOYO PARA LA TOMA DE DECISIONES. Entre los tipos de sistemas que apoyan el proceso de toma de decisiones se idntica los siguientes: Sistemas de Soporte para la Toma de Decisiones (DSS: Decision Support Systems) Apoyar la toma de decisiones mediante la generacin y evaluacin sistemtica de diferentes alternativas o escenarios de decisin. Un DSS no soluciona problemas, ya que solo apoya al proceso de toma de decisiones. La responsabilidad de tomar una decisin, de adoptar y de realizarla es de los administradores, no del DSS. Puede emplearse para obtener informacin que revele los elementos clave de los problemas y las relaciones entre ellos. Tambin puede usarse para identificar, crear y comunicar cursos de accin disponibles y alternativas de decisin. Sistemas de Soporte para la Toma de Decisiones de Grupo (Group Decisin Support Systems). Cubren el objetivo de lograr la participacin de un grupo de personas durante la toma de decisiones en ambientes de anonimato y consenso, apoyando decisiones simultaneas. Sistemas Expertos de Soporte para la Toma de Decisiones (DEss: Expert Decision Supprt Systems). Permiten cargar bases de conocimiento que se integran por una serie de reglas de sentido comn para que diferentes usuarios las consulten, apoyen la toma de decisiones, la capacitacin, etc. Sistemas de Informacin para Ejecutivos (EIS: Executive information Systems). Estn dirigidos a apoyar el proceso de toma de decisiones de los altos ejecutivos de una organizacin, presentado informacin relevante y usando recursos visuales de fcil interpretacin, con el ejecutivo de mantenerlos informados. Las principales caractersticas de estos sistemas son las siguientes: La Informacin que generan sirve de apoyo a los mandos intermedios y a la alta administracin en el proceso de toma de decisiones. Suelen ser intensivos en clculos y escasos en entrada y salidas de informacin. As, por ejemplo, un modelo de planeacin financiera requiere poca informacin de entrada, genera poca informacin como
56
resultado pero puede realizar muchos clculos durante su proceso. No suelen ahorrar mano de obra. Suelen ser interactivos y amigable, con altos estndares de diseo grafico y visual, ya que estn dirigidos al usuario final. Apoyan la toma de decisiones que por su misma naturaleza son estructuradas y no estructuradas. Estos sistemas pueden ser desarrollados directamente por el usuario final sin la participacin operativa de los analistas y programadores del rea de informtica. Cuestionario: 1. 2. 3. 4. 5. Cual es el objetivo de los sistemas de Informacin Definir el surgimiento de los sistemas de Informacin Que no es un sistema de informacin y porque. Cuales son los procesos del analista se un sistema de Informacin Explicar la Clasificacin de los Sistemas de Informacin y explicar el DSS
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
57
PROGRAMA DE CALIDAD UDABOL DIF 001

INTRODUCCIN A LOS CONCEPTOS BSICOS DE LA TEORA GENERAL DE SISTEMAS INTRODUCCIN En un sentido amplio, la Teora General de Sistemas (TGS) se presenta como una forma sistemtica y cientfica de aproximacin y representacin de la realidad y, al mismo tiempo, como una orientacin hacia una prctica estimulante para formas de trabajo transdisciplinarias. En tanto paradigma cientfico, la TGS se caracteriza por su perspectiva holstica e integradora, en donde lo importante son las relaciones y los conjuntos que a partir de ellas emergen. En tanto prctica, la TGS ofrece un ambiente adecuado para la interrelacin y comunicacin fecunda entre especialistas y especialidades. Bajo las consideraciones anteriores, la TGS es un ejemplo de perspectiva cientfica (Arnold & Rodrguez, 1990a). En sus distinciones conceptuales no hay explicaciones o relaciones con contenidos preestablecidos, pero s con arreglo a ellas podemos dirigir nuestra observacin, hacindola operar en contextos reconocibles. Los objetivos originales de la Teora General de Sistemas son los siguientes: a. Impulsar el desarrollo de una terminologa general que permita describir las caractersticas, funciones y comportamientos sistmicos. b. Desarrollar un conjunto de leyes aplicables a todos estos comportamientos y, por ltimo, c. Promover una formalizacin (matemtica) de estas leyes. La primera formulacin en tal sentido es atribuible al bilogo Ludwig Von Bertalanffy (1901-1972), quien acu la denominacin "Teora General de Sistemas". Para l, la TGS debera constituirse en un mecanismo de integracin entre las ciencias naturales y sociales y ser al mismo tiempo un instrumento bsico para la formacin y preparacin de cientficos. Sobre estas bases se constituy en 1954 la Society for General Systems Research, cuyos objetivos fueron los siguientes: a. Investigar el isomorfismo de conceptos, leyes y modelos en varios campos y facilitar las transferencias entre aquellos. b. Promocin y desarrollo de modelos tericos en campos que carecen de ellos. c. Reducir la duplicacin de los esfuerzos tericos d. Promover la unidad de la ciencia a travs de principios conceptuales y metodolgicos unificadores. Como ha sido sealado en otros trabajos, la perspectiva de la TGS surge en respuesta al agotamiento e inaplicabilidad de los enfoques analtico-reduccionistas y sus principios mecnico-causales (Arnold & Rodrguez, 1990b). Se desprende que el principio clave en que se basa la TGS es la nocin de totalidad orgnica, mientras que el paradigma anterior estaba fundado en una imagen inorgnica del mundo. A poco andar, la TGS concit un gran inters y pronto se desarrollaron bajo su alero diversas tendencias, entre las que destacan la ciberntica (N. Wiener), la teora de la informacin (C.Shannon y W.Weaver) y la dinmica de sistemas (J.Forrester). Si bien el campo de aplicaciones de la TGS no reconoce limitaciones, al usarla en fenmenos humanos, sociales y culturales se advierte que sus races estn en el rea de los sistemas naturales (organismos) y en el de los sistemas artificiales (mquinas).
58
Mientras ms equivalencias reconozcamos entre organismos, mquinas, hombres y formas de organizacin social, mayores sern las posibilidades para aplicar correctamente el enfoque de la TGS, pero mientras ms experimentemos los atributos que caracterizan lo humano, lo social y lo cultural y sus correspondientes sistemas, quedarn en evidencia sus inadecuaciones y deficiencias (sistemas triviales). No obstante sus limitaciones, y si bien reconocemos que la TGS aporta en la actualidad slo aspectos parciales para una moderna Teora General de Sistemas Sociales (TGSS), resulta interesante examinarla con detalle. Entendemos que es en ella donde se fijan las distinciones conceptuales fundamentales que han facilitado el camino para la introduccin de su perspectiva, especialmente en los estudios ecolgico culturales (e.g. M.Sahlins, R.Rappaport), politolgicos (e.g. K.Deutsch, D.Easton), organizaciones y empresas (e.g. D.Katz y R.Kahn) y otras especialidades antropolgicas y sociolgicas. DEFINICIONES NOMINALES PARA SISTEMAS GENERALES Siempre que se habla de sistemas se tiene en vista una totalidad cuyas propiedades no son atribuibles a la simple adicin de las propiedades de sus partes o componentes. En las definiciones ms corrientes se identifican los sistemas como conjuntos de elementos que guardan estrechas relaciones entre s, que mantienen al sistema directo o indirectamente unido de modo ms o menos estable y cuyo comportamiento global persigue, normalmente, algn tipo de objetivo (teleologa). Esas definiciones que nos concentran fuertemente en procesos sistmicos internos deben, necesariamente, ser complementadas con una concepcin de sistemas abiertos, en donde queda establecida como condicin para la continuidad sistmica el establecimiento de un flujo de relaciones con el ambiente. A partir de ambas consideraciones la TGS puede ser desagregada, dando lugar a dos grandes grupos de estrategias para la investigacin en sistemas generales: a. Las perspectivas de sistemas en donde las distinciones conceptuales se concentran en una relacin entre el todo (sistema) y sus partes (elementos). b. Las perspectivas de sistemas en donde las distinciones conceptuales se concentran en los procesos de frontera (sistema/ambiente). En el primer caso, la cualidad esencial de un sistema est dada por la interdependencia de las partes que lo integran y el orden que subyace a tal interdependencia. En el segundo, lo central son las corrientes de entradas y de salidas mediante las cuales se establece una relacin entre el sistema y su ambiente. Ambos enfoques son ciertamente complementarios. CLASIFICACIONES BSICAS DE SISTEMAS GENERALES Es conveniente advertir que no obstante su papel renovador para la ciencia clsica, la TGS no se despega en lo fundamental del modo cartesiano (separacin sujeto/objeto). As forman parte de sus problemas tanto la definicin del status de realidad de sus objetos, como el desarrollo de un instrumental analtico adecuado para el tratamiento lineal de los comportamientos sistmicos (esquema de causalidad). Bajo ese marco de referencia los sistemas pueden clasificarse de las siguientes maneras: a. Segn su entitividad los sistemas pueden ser agrupados en reales, ideales y modelos. Mientras los primeros presumen una existencia independiente del observador (quien los puede descubrir), los segundos son construcciones simblicas, como el caso de la lgica y las matemticas, mientras que el tercer tipo corresponde a abstracciones de la realidad, en donde se combina lo conceptual con las caractersticas de los objetos. b. Con relacin a su origen los sistemas pueden ser naturales o artificiales, distincin que apunta a destacar la dependencia o no en su estructuracin por parte de otros sistemas. c. Con relacin al ambiente o grado de aislamiento los sistemas pueden ser cerrados o abiertos, segn el tipo de intercambio que establecen con sus ambientes. Como se sabe, en este punto se han producido importantes
59
innovaciones en la TGS (observacin de segundo orden), tales como las nociones que se refieren a procesos que aluden a estructuras disipativas, auto referencialidad, auto observacin, auto descripcin, autoorganizacin, reflexin y autopoiesis (Arnold,M. & D.Rodrguez. 1991). BASES EPISTEMOLGICAS DE LA TEORA GENERAL DE SISTEMAS Segn Bertalanffy (1976) se puede hablar de una filosofa de sistemas, ya que toda teora cientfica de gran alcance tiene aspectos metafsicos. El autor seala que "teora" no debe entenderse en su sentido restringido, esto es, matemtico, sino que la palabra teora est ms cercana, en su definicin, a la idea de paradigma de Kuhn. El distingue en la filosofa de sistemas una ontologa de sistemas, una epistemologa de sistemas y una filosofa de valores de sistemas. La ontologa se aboca a la definicin de un sistema y al entendimiento de cmo estn plasmados los sistemas en los distintos niveles del mundo de la observacin, es decir, la ontologa se preocupa de problemas tales como el distinguir un sistema real de un sistema conceptual. Los sistemas reales son, por ejemplo, galaxias, perros, clulas y tomos. Los sistemas conceptuales son la lgica, las matemticas, la msica y, en general, toda construccin simblica. Bertalanffy entiende la ciencia como un subsistema del sistema conceptual, definindola como un sistema abstrado, es decir, un sistema conceptual correspondiente a la realidad. El seala que la distincin entre sistema real y conceptual est sujeta a debate, por lo que no debe considerarse en forma rgida. La epistemologa de sistemas se refiere a la distancia de la TGS con respecto al positivismo o empirismo lgico. Bertalanffy, refirindose a si mismo, dice: "En filosofa, la formacin del autor sigui la tradicin del neopositivismo del grupo de Moritz Schlick, posteriormente llamado Crculo de Viena. Pero, como tena que ser, su inters en el misticismo alemn, el relativismo histrico de Spengler y la historia del arte, aunado a otras actitudes no ortodoxas, le impidi llegar a ser un buen positivista. Eran ms fuertes sus lazos con el grupo berlins de la Sociedad de Filosofa Emprica en los aos veintitantos; all descollaban el filsofo-fsico Hans Reichenbach, el psiclogo A. Herzberg y el ingeniero Parseval (inventor del dirigible)". Bertalanffy seala que la epistemologa del positivismo lgico es fisicalista y atomista. Fisicalista en el sentido que considera el lenguaje de la ciencia de la fsica como el nico lenguaje de la ciencia y, por lo tanto, la fsica como el nico modelo de ciencia. Atomista en el sentido que busca fundamentos ltimos sobre los cuales asentar el conocimiento, que tendran el carcter de indubitable. Por otro lado, la TGS no comparte la causalidad lineal o unidireccional, la tesis que la percepcin es una reflexin de cosas reales o el conocimiento una aproximacin a la verdad o la realidad. Bertalanffy seala "[La realidad] es una interaccin entre conocedor y conocido, dependiente de mltiples factores de naturaleza biolgica, psicolgica, cultural, lingstica, etc. La propia fsica nos ensea que no hay entidades ltimas tales como corpsculos u ondas, que existan independientemente del observador. Esto conduce a una filosofa perspectivista para la cual la fsica, sin dejar de reconocerle logros en su campo y en otros, no representa el monopolio del conocimiento. Frente al reduccionismo y las teoras que declaran que la realidad no es nada sino (un montn de partculas fsicas, genes, reflejos, pulsiones o lo que sea), vemos la ciencia como una de las perspectivas que el hombre, con su dotacin y servidumbre biolgica, cultural y lingstica, ha creado para vrselas con el universo al cual est arrojado o ms bien, al que est adaptado merced a la evolucin y la historia". La filosofa de valores de sistemas se preocupa de la relacin entre los seres humanos y el mundo, pues Bertalanffy seala que la imagen de ser humano diferir si se entiende el mundo como partculas fsicas gobernadas por el azar o como un orden jerrquico simblico. La TGS no acepta ninguna de esas visiones de mundo, sino que opta por una visin heurstica. Finalmente, Bertalanffy reconoce que la teora de sistemas comprende un conjunto de enfoques que difieren en estilo y propsito, entre las cuales se encuentra la teora de conjuntos (Mesarovic) , teora de las redes (Rapoport), ciberntica (Wiener), teora de la informacin (Shannon y Weaver), teora de los autmatas (Turing), teora de los juegos (Von Neumann), entre otras. Por eso, la prctica del anlisis aplicado de sistemas tiene que aplicar diversos modelos, de acuerdo con la naturaleza del caso y con criterios operacionales, aun cuando algunos conceptos, modelos y principios de la TGS
60
como el orden jerrquico, la diferenciacin progresiva, la retroalimentacin, etc. son aplicables a grandes rasgos a sistemas materiales, psicolgicos y socioculturales. CONCEPTOS BSICOS DE LA TEORA GENERAL DE SISTEMAS AMBIENTE Se refiere al rea de sucesos y condiciones que influyen sobre el comportamiento de un sistema. En lo que a complejidad se refiere, nunca un sistema puede igualarse con el ambiente y seguir conservando su identidad como sistema. La nica posibilidad de relacin entre un sistema y su ambiente implica que el primero debe absorber selectivamente aspectos de ste. Sin embargo, esta estrategia tiene la desventaja de especializar la selectividad del sistema respecto a su ambiente, lo que disminuye su capacidad de reaccin frente a los cambios externos. Esto ltimo incide directamente en la aparicin o desaparicin de sistemas abiertos. ATRIBUTO Se entiende por atributo las caractersticas y propiedades estructurales o funcionales que caracterizan las partes o componentes de un sistema. CIBERNETICA Se trata de un campo interdisciplinario que intenta abarcar el mbito de los procesos de control y de comunicacin (retroalimentacin) tanto en mquinas como en seres vivos. El concepto es tomado del griego kibernetes que nos refiere a la accin de timonear una goleta (N.Wiener.1979). CIRCULARIDAD Concepto ciberntico que nos refiere a los procesos de autocausacin. Cuando A causa B y B causa C, pero C causa A, luego A en lo esencial es autocausado (retroalimentacin, morfostsis, morfognesis). COMPLEJIDAD Por un lado, indica la cantidad de elementos de un sistema (complejidad cuantitativa) y, por el otro, sus potenciales interacciones (conectividad) y el nmero de estados posibles que se producen a travs de stos (variedad, variabilidad). La complejidad sistmica est en directa proporcin con su variedad y variabilidad, por lo tanto, es siempre una medida comparativa. Una versin ms sofisticada de la TGS se funda en las nociones de diferencia de complejidad y variedad. Estos fenmenos han sido trabajados por la ciberntica y estn asociados a los postulados de R.Ashby (1984), en donde se sugiere que el nmero de estados posibles que puede alcanzar el ambiente es prcticamente infinito. Segn esto, no habra sistema capaz de igualar tal variedad, puesto que si as fuera la identidad de ese sistema se diluira en el ambiente. CONGLOMERADO Cuando la suma de las partes, componentes y atributos en un conjunto es igual al todo, estamos en presencia de una totalidad desprovista de sinergia, es decir, de un conglomerado (Johannsen. 1975:31-33). ELEMENTO Se entiende por elemento de un sistema las partes o componentes que lo constituyen. Estas pueden referirse a objetos o procesos. Una vez identificados los elementos pueden ser organizados en un modelo. ENERGIA La energa que se incorpora a los sistemas se comporta segn la ley de la conservacin de la energa, lo que quiere decir que la cantidad de energa que permanece en un sistema es igual a la suma de la energa importada menos la suma de la energa exportada (entropa, negentropa). ENTROPIA
61
El segundo principio de la termodinmica establece el crecimiento de la entropa, es decir, la mxima probabilidad de los sistemas es su progresiva desorganizacin y, finalmente, su homogeneizacin con el ambiente. Los sistemas cerrados estn irremediablemente condenados a la desorganizacin. No obstante hay sistemas que, al menos temporalmente, revierten esta tendencia al aumentar sus estados de organizacin (negentropa, informacin). EQUIFINALIDAD Se refiere al hecho que un sistema vivo a partir de distintas condiciones iniciales y por distintos caminos llega a un mismo estado final. El fin se refiere a la manutencin de un estado de equilibrio fluyente. "Puede alcanzarse el mismo estado final, la misma meta, partiendo de diferentes condiciones iniciales y siguiendo distintos itinerarios en los procesos organsmicos" (Von Bertalanffy. 1976:137). El proceso inverso se denomina multifinalidad, es decir, "condiciones iniciales similares pueden llevar a estados finales diferentes" (Buckley. 1970:98). EQUILIBRIO Los estados de equilibrios sistmicos pueden ser alcanzados en los sistemas abiertos por diversos caminos, esto se denomina equifinalidad y multifinalidad. La mantencin del equilibrio en sistemas abiertos implica necesariamente la importacin de recursos provenientes del ambiente. Estos recursos pueden consistir en flujos energticos, materiales o informativos. EMERGENCIA Este concepto se refiere a que la descomposicin de sistemas en unidades menores avanza hasta el lmite en el que surge un nuevo nivel de emergencia correspondiente a otro sistema cualitativamente diferente. E. Morin (Arnold. 1989) seal que la emergencia de un sistema indica la posesin de cualidades y atributos que no se sustentan en las partes aisladas y que, por otro lado, los elementos o partes de un sistema actualizan propiedades y cualidades que slo son posibles en el contexto de un sistema dado. Esto significa que las propiedades inmanentes de los componentes sistmicos no pueden aclarar su emergencia. ESTRUCTURA Las interrelaciones ms o menos estables entre las partes o componentes de un sistema, que pueden ser verificadas (identificadas) en un momento dado, constituyen la estructura del sistema. Segn Buckley (1970) las clases particulares de interrelaciones ms o menos estables de los componentes que se verifican en un momento dado constituyen la estructura particular del sistema en ese momento, alcanzando de tal modo una suerte de "totalidad" dotada de cierto grado de continuidad y de limitacin. En algunos casos es preferible distinguir entre una estructura primaria (referida a las relaciones internas) y una hiper estructura (referida a las relaciones externas). FRONTERA Los sistemas consisten en totalidades y, por lo tanto, son indivisibles como sistemas (sinergia). Poseen partes y componentes (subsistema), pero estos son otras totalidades (emergencia). En algunos sistemas sus fronteras o lmites coinciden con discontinuidades estructurales entre estos y sus ambientes, pero corrientemente la demarcacin de los lmites sistmicos queda en manos de un observador (modelo). En trminos operacionales puede decirse que la frontera del sistema es aquella lnea que separa al sistema de su entorno y que define lo que le pertenece y lo que queda fuera de l (Johannsen. 1975:66). FUNCION Se denomina funcin al output de un sistema que est dirigido a la mantencin del sistema mayor en el que se encuentra inscrito. HOMEOSTASIS Este concepto est especialmente referido a los organismos vivos en tanto sistemas adaptables. Los procesos homeostticos operan ante variaciones de las condiciones del ambiente, corresponden a las compensaciones internas al sistema que sustituyen, bloquean o complementan estos cambios con el objeto de mantener invariante la estructura sistmica, es decir, hacia la conservacin de su forma. La mantencin de formas dinmicas o trayectorias se denomina
62
homeorrosis (sistemas cibernticos). INFORMACION La informacin tiene un comportamiento distinto al de la energa, pues su comunicacin no elimina la informacin del emisor o fuente. En trminos formales "la cantidad de informacin que permanece en el sistema (...) es igual a la informacin que existe ms la que entra, es decir, hay una agregacin neta en la entrada y la salida no elimina la informacin del sistema" (Johannsen. 1975:78). La informacin es la ms importante corriente negentrpica de que disponen los sistemas complejos. INPUT / OUTPUT (modelo de) Los conceptos de input y output nos aproximan instrumentalmente al problema de las fronteras y lmites en sistemas abiertos. Se dice que los sistemas que operan bajo esta modalidad son procesadores de entradas y elaboradores de salidas. Input Todo sistema abierto requiere de recursos de su ambiente. Se denomina input a la importacin de los recursos (energa, materia, informacin) que se requieren para dar inicio al ciclo de actividades del sistema. Output Se denomina as a las corrientes de salidas de un sistema. Los outputs pueden diferenciarse segn su destino en servicios, funciones y retroinputs. ORGANIZACIN N. Wiener plante que la organizacin deba concebirse como "una interdependencia de las distintas partes organizadas, pero una interdependencia que tiene grados. Ciertas interdependencias internas deben ser ms importantes que otras, lo cual equivale a decir que la interdependencia interna no es completa" (Buckley. 1970:127). Por lo cual la organizacin sistmica se refiere al patrn de relaciones que definen los estados posibles (variabilidad) para un sistema determinado. MODELO Los modelos son constructos diseados por un observador que persigue identificar y mensurar relaciones sistmicas complejas. Todo sistema real tiene la posibilidad de ser representado en ms de un modelo. La decisin, en este punto, depende tanto de los objetivos del modelador como de su capacidad para distinguir las relaciones relevantes con relacin a tales objetivos. La esencia de la modelstica sistmica es la simplificacin. El metamodelo sistmico ms conocido es el esquema input-output. MORFOGENESIS Los sistemas complejos (humanos, sociales y culturales) se caracterizan por sus capacidades para elaborar o modificar sus formas con el objeto de conservarse viables (retroalimentacin positiva). Se trata de procesos que apuntan al desarrollo, crecimiento o cambio en la forma, estructura y estado del sistema. Ejemplo de ello son los procesos de diferenciacin, la especializacin, el aprendizaje y otros. En trminos cibernticos, los procesos causales mutuos (circularidad) que aumentan la desviacin son denominados morfogenticos. Estos procesos activan y potencian la posibilidad de adaptacin de los sistemas a ambientes en cambio. MORFOSTASIS Son los procesos de intercambio con el ambiente que tienden a preservar o mantener una forma, una organizacin o un estado dado de un sistema (equilibrio, homeostasis, retroalimentacin negativa). Procesos de este tipo son caractersticos de los sistemas vivos. En una perspectiva ciberntica, la morfostsis nos remite a los procesos causales mutuos que reducen o controlan las desviaciones. NEGENTROPIA Los sistemas vivos son capaces de conservar estados de organizacin improbables (entropa). Este fenmeno
63
aparentemente contradictorio se explica porque los sistemas abiertos pueden importar energa extra para mantener sus estados estables de organizacin e incluso desarrollar niveles ms altos de improbabilidad. La negentropa, entonces, se refiere a la energa que el sistema importa del ambiente para mantener su organizacin y sobrevivir (Johannsen. 1975). OBSERVACION (de segundo orden) Se refiere a la nueva ciberntica que incorpora como fundamento el problema de la observacin de sistemas de observadores: se pasa de la observacin de sistemas a la observacin de sistemas de observadores. RECURSIVIDAD Proceso que hace referencia a la introduccin de los resultados de las operaciones de un sistema en l mismo (retroalimentacin). RELACION Las relaciones internas y externas de los sistemas han tomado diversas denominaciones. Entre otras: efectos recprocos, interrelaciones, organizacin, comunicaciones, flujos, prestaciones, asociaciones, intercambios, interdependencias, coherencias, etctera. Las relaciones entre los elementos de un sistema y su ambiente son de vital importancia para la comprensin del comportamiento de sistemas vivos. Las relaciones pueden ser recprocas (circularidad) o unidireccionales. Presentadas en un momento del sistema, las relaciones pueden ser observadas como una red estructurada bajo el esquema input / output. RETROALIMENTACION Son los procesos mediante los cuales un sistema abierto recoge informacin sobre los efectos de sus decisiones internas en el medio, informacin que acta sobre las decisiones (acciones) sucesivas. La retroalimentacin puede ser negativa (cuando prima el control) o positiva (cuando prima la amplificacin de las desviaciones). Mediante los mecanismos de retroalimentacin, los sistemas regulan sus comportamientos de acuerdo a sus efectos reales y no a programas de outputs fijos. En los sistemas complejos estn combinados ambos tipos de corrientes (circularidad, homeostasis). RETROALIMENTACIN NEGATIVA Este concepto est asociado a los procesos de autorregulacin u homeostticos. Los sistemas con retroalimentacin negativa se caracterizan por la mantencin de determinados objetivos. En los sistemas mecnicos los objetivos quedan instalados por un sistema externo (el hombre u otra mquina). RETROALIMENTACIN POSITIVA Indica una cadena cerrada de relaciones causales en donde la variacin de uno de sus componentes se propaga en otros componentes del sistema, reforzando la variacin inicial y propiciando un comportamiento sistmico caracterizado por un autorreforzamiento de las variaciones (circularidad, morfognesis). La retroalimentacin positiva est asociada a los fenmenos de crecimiento y diferenciacin. Cuando se mantiene un sistema y se modifican sus metas/fines nos encontramos ante un caso de retroalimentacin positiva. En estos casos se aplica la relacin desviacin-amplificacin (Mayurama. 1963). RETROINPUT Se refiere a las salidas del sistema que van dirigidas al mismo sistema (retroalimentacin). En los sistemas humanos y sociales stos corresponden a los procesos de autorreflexin. SERVICIO Son los outputs de un sistema que van a servir de inputs a otros sistemas o subsistemas equivalentes. SINERGIA Todo sistema es sinrgico en tanto el examen de sus partes en forma aislada no puede explicar o predecir su comportamiento. La sinergia es, en consecuencia, un fenmeno que surge de las interacciones entre las partes o
64
componentes de un sistema (conglomerado). Este concepto responde al postulado aristotlico que dice que "el todo no es igual a la suma de sus partes". La totalidad es la conservacin del todo en la accin recproca de las partes componentes (teleologa). En trminos menos esencialistas, podra sealarse que la sinergia es la propiedad comn a todas aquellas cosas que observamos como sistemas. SISTEMAS (dinmica de) Comprende una metodologa para la construccin de modelos de sistemas sociales, que establece procedimientos y tcnicas para el uso de lenguajes formalizados, considerando en esta clase a sistemas socioeconmicos, sociolgicos y psicolgicos, pudiendo aplicarse tambin sus tcnicas a sistemas ecolgicos. Esta tiene los siguientes pasos: a) observacin del comportamiento de un sistema real, b) identificacin de los componentes y procesos fundamentales del mismo, c) identificacin de las estructuras de retroalimentacin que permiten explicar su comportamiento, d) construccin de un modelo formalizado sobre la base de la cuantificacin de los atributos y sus relaciones, e) introduccin del modelo en un computador y f) trabajo del modelo como modelo de simulacin (Forrester). SISTEMAS ABIERTOS Se trata de sistemas que importan y procesan elementos (energa, materia, informacin) de sus ambientes y esta es una caracterstica propia de todos los sistemas vivos. Que un sistema sea abierto significa que establece intercambios permanentes con su ambiente, intercambios que determinan su equilibrio, capacidad reproductiva o continuidad, es decir, su viabilidad (entropa negativa, teleologa, morfognesis, equifinalidad). SISTEMAS CERRADOS Un sistema es cerrado cuando ningn elemento de afuera entra y ninguno sale fuera del sistema. Estos alcanzan su estado mximo de equilibrio al igualarse con el medio (entropa, equilibrio). En ocasiones el trmino sistema cerrado es tambin aplicado a sistemas que se comportan de una manera fija, rtmica o sin variaciones, como sera el caso de los circuitos cerrados. SISTEMAS CIBERNETICOS Son aquellos que disponen de dispositivos internos de autocomando (autorregulacin) que reaccionan ante informaciones de cambios en el ambiente, elaborando respuestas variables que contribuyen al cumplimiento de los fines instalados en el sistema (retroalimentacin, homeorrosis). SISTEMAS TRIVIALES Son sistemas con comportamientos altamente predecibles. Responden con un mismo output cuando reciben el input correspondiente, es decir, no modifican su comportamiento con la experiencia. SUBSISTEMA Se entiende por subsistemas a conjuntos de elementos y relaciones que responden a estructuras y funciones especializadas dentro de un sistema mayor. En trminos generales, los subsistemas tienen las mismas propiedades que los sistemas (sinergia) y su delimitacin es relativa a la posicin del observador de sistemas y al modelo que tenga de stos. Desde este ngulo se puede hablar de subsistemas, sistemas o supersistemas, en tanto stos posean las caractersticas sistmicas (sinergia). TELEOLOGIA Este concepto expresa un modo de explicacin basado en causas finales. Aristteles y los Escolsticos son considerados como teleolgicos en oposicin a las causalistas o mecanicistas. VARIABILIDAD Indica el mximo de relaciones (hipotticamente) posibles (n!). VARIEDAD
65
Comprende el nmero de elementos discretos en un sistema (v = cantidad de elementos). VIABILIDAD Indica una medida de la capacidad de sobrevivencia y adaptacin (morfostsis, morfognesis) de un sistema a un medio en cambio.
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
66

CONCEPCIN DEL ANLISIS ESTRUCTURADO RESUMEN En este artculo se expondrn los tpicos relacionados a la transicin por la que ha tenido que pasar el Anlisis Estructurado. Segn Pressman "Fue la aparicin del diseo y la programacin estructurada alrededor de los aos 60s la que dieron cabida al surgimiento del anlisis estructurado, ya que exista la necesidad de utilizar una notacin grfica para representar los datos y los procesos que los transforman". Es por ello que surgen una serie de temas afines tales como: herramientas automatizadas (CASE), prototipos, diagramas de entidad-relacin etc. Pero las preguntas que todos nos hacemos: qu nos espera en un futuro no muy lejano del anlisis estructurado con la introduccin de nuevas variantes? Desaparecer? o se mantendr? NDICE DE TRMINOS RELACIONADOS CASE (Ingeniera de Software Auxiliada por Computadora), elaboracin de prototipos, smbolos grficos, diccionarios de datos, descripciones de procesos y procedimientos, reglas, diagramas de estados, diagramas de entidad-relacin, diagramas de transicin de eventos, divisin de eventos, modelos esenciales y modelos de implantacin. INTRODUCCIN A lo largo de los aos hemos visto una evolucin de ideas y tcnicas en el campo del anlisis de sistemas. La cual cabe en tres perodos amplios segn Yourdon: 1. El anlisis de sistema convencional, anterior a los aos 70s, caracterizado por especificaciones tipo novela victoriana que eran difciles de leer y entender, y casi imposibles de mantener. 2. El anlisis estructurado clsico, de mediados de los aos 70s, a mediados de los aos 80s. Esto se caracteriz por primeras versiones de modelos grficos, y nfasis en el modelado de las implementaciones actuales de un sistema antes de modelar el nuevo. 3. El anlisis estructurado moderno, en el cual se introducen mejoras sobre todo para modelar sistemas de tiempo real y relaciones de situaciones complejas. Aumentando por ende la comunicacin entre el analista y el sistema. En la actualidad las tcnicas modernas estn siendo fusionadas, para as lograr un mejor mtodo que pueda hacerle frente a las necesidades de las diferentes fases del ciclo de vida del sistema, incluyendo a la fase de anlisis. Obteniendo de est manera mejores resultados que pueda interpretar el analista en forma rpida y precisa. CONCEPCIN En primera instancia debemos decir que el anlisis estructurado segn Senn "permite al analista conocer un sistema o proceso (actividad) en una forma lgica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningn detalle pertinente". El objetivo que persigue el anlisis estructurado es organizar las tareas asociadas con la determinacin de requerimientos para obtener la comprensin completa y exacta de una situacin dada. Se puede decir adicionalmente que los componentes del anlisis estructurado son los siguientes: smbolos grficos, diccionarios de datos, descripciones de procesos y procedimientos, reglas. Despus de relacionarnos brevemente con la terminologa bsica, podemos entrar en aspectos relacionados con los cambios del anlisis estructurado.
67
Podemos decir que para finales de los aos 60s e inicios de los 70s el anlisis estructurado surge de la necesidad de buscar una forma interpretativa ms rpida y eficiente, de tal manera que se pudiesen definir los requerimientos del usuario y las especificaciones funcionales del sistema. Pero esto no se daba porque lo que exista eran grandes volmenes de informacin que haba que leer por completo y que acarreaban una serie de problemas de: monolitismo, redundancia, ambigedad e imposibilidad de mantener. Es por ello que surge una amplia variedad de diagramas que permiten representar las especificaciones funcionales en forma sencilla y rpida, aumentando por ende el grado de comunicacin entre las especificaciones funcionales y el usuario final (analista, programador, diseador). Posteriormente, a mediados de los aos 70s estando el anlisis estructurado clsico en su apogeo aparecen una serie de dificultades que limitan al analista hacer un buen desempeo de sus actividades. Entre estos problemas segn Yourdon podemos mencionar:

Distincin difusa y poca, definida entre los modelos lgicos y los modelos fsicos. Limitacin para modelar sistemas en tiempo real. El modelo de datos se haca de una manera primitiva.
Estas y otras razones dieron nacimiento a ciertas mejoras en el anlisis estructurado clsico tales como: diagramas de entidad-relacin, diagramas de transicin de estados, divisin de eventos, modelos esenciales y modelos de implantacin. Pero a pesar de esto segn Yourdon se siguieron dando ms problemas como los siguientes:

Tras la segunda y tercera correcciones de un diagrama, el analista se volva cada vez ms apuesto y renuente a hacer ms cambios. Debido a la cantidad de trabajo requerido, el analista dejaba a veces de dividir el modelo del sistema en modelos de menor nivel, quedando por ende, funciones primitivas. A menudo no se incorporaban en el modelo del sistema los cambios en los requerimientos del usuario sino hasta despus de la fase de anlisis del proyecto.
Inclusive las correcciones de los diagramas haba que hacerlas en forma manual, para asegurar que fuesen consistentes y estuviesen completas; lo cual era bastante tedioso y dejaba por fuera muchos errores que deban de encontrarse. Pero para mediados de los 80s aparecieron las herramientas CASE que trataron de subsanar estos problemas. Las herramientas CASE (Ingeniera de software auxiliada por computadora) se utilizan para dibujar diagramas de flujo de datos y otros adems de llevar a cabo una variedad de labores de revisin de errores. Finalmente, algunos usuarios tenan dificultades al tratar con los modelos grficos del anlisis estructurado y preferan alguna otra forma de modelar los requerimientos y comportamiento del sistema; es por ello que aparecen las herramientas de generacin de prototipos (mediados de los 80s) que son considerados como una alternativa al anlisis estructurado para tales usuarios. Tambin se utiliza para recordar en forma breve y precisa lo que se ha hecho a lo largo de todo el desarrollo del sistema, para no perder la secuencia de lo que se est realizando. En la actualidad muchas de estas herramientas se estn utilizando para facilitar la fase de anlisis, e inclusive se estn elaborando o fusionando lo mejor de cada una de las tcnicas que atienden las necesidades de todas las fases del ciclo de vida del sistema; para as obtener un mejor aprovechamiento, entendimiento, y rendimiento al momento que se ponga a correr el sistema. Disminuyendo de esta manera la serie de errores que se cometan anteriormente, con la introduccin de herramientas ms especializadas y fciles de utilizar. FUTURO Diversos aspectos del anlisis estructurado han cambiado gradualmente a lo largo de los ltimos aos. Las principales reas de cambio incluyen lo siguiente segn Yourdon:
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
68
Cambios de terminologa. Particin de acontecimientos. La desenfatizacin del modelado fsico actual. Herramientas de modelado en tiempo real. Integracin ms cercana del modelado de procesos y datos.
En un futuro no muy lejano se piensa que se darn, si es que ya no se estn dando, los siguientes cambios o pautas en el mbito total en lo que se refiere a anlisis segn Yourdon:
Mayor difusin del anlisis de sistemas, sobre todo en los siguientes grupos: los niveles superiores de administracin en organizaciones gubernamentales y de negocios, los nios, y profesionales de la computacin en los pases del tercer mundo. Impacto sobre la industria de software del tercer mundo. Proliferacin de las herramientas automatizadas, aunque no todos los analistas tienen acceso a las ltimas herramientas de anlisis. Impacto de los desastres de mantenimiento. Integracin del anlisis estructurado con la inteligencia artificial.
Podemos adicionar que el futuro del anlisis estructurado va a depender mucho tambin de que tan rpido pueda ajustarse el mismo a los cambios tecnolgicos que se viven hoy en da. Actualmente, existen otras tcnicas en otras reas como lo es la orientada a objetos, la cual preve un buen futuro y muchas mejoras para los sistemas actuales, y que de alguna forma va dejando atrs a la tcnica del anlisis estructurado.
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
69
PROGRAMA DE CALIDAD UDABOL DIF 003 RELACIN: GESTIN DE PROYECTOS Y ANLSIS DE SISTEMAS
QU LE PASA A UN PROYECTO? Observe los siguientes cuadros, y redacte un texto acerca del concepto encerrado acerca de la determinacin de requerimientos que tiene un sistema cualquiera.
Los proyectos estn regidos por los requerimientos:
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
70
PROYECTO Es la combinacin de recursos humanos y no humanos reunidos en una organizacin temporal para conseguir un propsito determinado David I. Cleland and William R. King Systems Analysis and Project Management Emprendimiento temporario realizado para crear un producto o servicio nico Project Management Institute Son instrumentos para responder a requerimientos que no pueden ser atendidos dentro de lo lmites operacionales normales de la organizacin. Cesan cuando el objetivo ha sido alcanzado o cuando no es posible alcanzarlos y se cancelan
QU ES GERENCIA DE PROYECTOS? La aplicacin de conocimiento, habilidades, herramientas y tcnicas a las actividades de un proyecto a fin de cumplir con los requerimientos de un proyecto Tomado de: A Guide to the Project Management Body of Knowledge (PMBOK Guide) SE LOGRAN PROYECTOS EXITOSOS SOLO CON EL DESEO DEL EQUIPO DE TRABAJO? Tienen que ser un objetivo estratgico de la organizacin tener: Profesionales capacitados Herramientas y metodologas establecidas Cultura organizacional que respalde la disciplina de Direccin de Proyectos
POR QU GERENCIA DE PROYECTOS? Una Gerencia de Proyectos disciplinada provee: Metodologa para comunicaciones, coordinacin, y control efectivos. Un plan para medir el avance. nfasis en un desempeo que logre proyectos dentro del presupuesto, en el tiempo establecido y que satisfaga los requerimientos del cliente.
La Gerencia de Proyectos provee el marco conceptual para los mtodos, procesos, monitoreo y control de cambios.
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
71
PROGRAMA DE CALIDAD UDABOL DIF 004 WBS (Work Breakdown Structure, Estructura de Desagregacin de Trabajo)
Estructura de desagregacin del alcance del proyecto orientada a entregables. Es una divisin del alcance del proyecto en paquetes para facilitar la definicin y la gestin del trabajo. Es una jerarqua de entregables que van a ser generados para lograr los objetivos del proyecto. Trabajo no especificado en el WBS, no se hace. Figura: Estructura WBS
REGLAS PARA LA DESCOMPOSICIN Subdividir siguiendo las reas o lneas funcionales del objeto del proyecto y no las lneas de la organizacin. Es posible estructurar el proyecto en base a sus componentes. Todas las tareas deben tener: Objetivo o propsito de la tarea Resultados esperados Recursos necesarios Plazos previstos Hiptesis consideradas Presupuesto asignado Ejemplo: Construccin de una casa en el campo.
En Microsoft Project:
Figura 2. Planificacin en Microsoft Project
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
72
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
73
PROGRAMA DE CALIDAD UDABOL DIF 005 DIAGRAMA DE FLUJO DE DATOS DFD QU ES UN DIAGRAMA DE FLUJO? Es una herramienta que permite visualizar un sistema como una red de procesos funcionales, conectados entre s por conductos y tanques de almacenamiento de datos. Proporciona un punto de vista de un sistema, el orientado a funciones. Podemos encontrarlo en la literatura con los siguientes sinnimos: Carta de burbujas. DFD (abreviatura que usaremos). Diagrama de burbujas. Modelo de proceso. Diagrama de flujo de trabajo. Modelo de funcin. Una imagen de lo que sucede.
Un poco de Historia. Los DFD se utilizaron por primera vez en la ingeniera de software como notacin para el diseo de sistemas (por ejemplo, en los libros y artculos de diseo estructurado tales como [STEVENS, MYERES y CONSTANTINE, 1974] y otros). A su vez, la notacin se toma prestada de artculos anteriores sobre teora de grficas, y contina siendo utilizada por los ingenieros de software que trabajan en la implantacin directa de modelos de los requerimientos del usuario. Gua para la construccin de un DFD. Algunas de estas reglas ayudan a no elaborar un DFD errneo (como incompleto o inconsistente). Adems puede ayudarle a que aumentar las probabilidades de que el usuario lo lea con mas cuidado. Recuerde: Las Reglas incluyen las siguientes: Elegir nombres con significado para los procesos, flujos, almacenes y terminadores. Numerar los procesos. Redibujar el DFD tantas veces como sea necesario estticamente. Evitar los DFD demasiado complejos. Asegurarse de que el DFD sea internamente consistente y que tambin lo sea con cualquier DFD relacionado con l. Elegir nombres con significado para los procesos, flujos, almacenes y terminadores Un proceso en un DFD puede identificar una funcin que se est llevando a cabo, o puede identificar como se est llevando a cabo identificando a la persona o grupo; en este ltimo caso identifique la tarea que se realiza no nombres de personas. Etiquete los procesos de manera que se puedan identificar las funciones que el sistema est llevando a cabo. Un buen sistema que se puede utilizar para nombrar procesos es usar un verbo y un objeto. Es decir, elegir un verbo activo y un objeto apropiado para formar una frase descriptiva para el proceso.
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
74
Ejemplos de nombres de procesos:

CALCULAR TRAYECTORIA DE PROYECTIL. PRODUCIR INFORME DE INVENTARIO. VALIDAR NUMERO TELEFONICO. ASIGNAR ESTUDIANTE A LA CLASE.
Pedro nombre invlido para un proceso. Resultar fcil utilizar verbos y objetos especficos si el proceso es relativamente simple y est bien definido. Sin embargo, an en casos sencillos hay tentacin por utilizar nombres ambiguos como: HACER, MANEJAR y PROCESAR. Cuando se utilizan verbos tan elsticos (con significados para cubrir casi cualquier situacin) a menudo significa que el analista no est seguro de cual funcin se est llevando a cabo o que se han agrupado diversas funciones que en realidad no debieran agruparce. Estos son algunos nombres de proceso no adecuados: HACER ALGO. MANEJAR ENTRADAS. ENCARGARCE DE PROCESOS. EDICIN GENERAL. Los nombres de procesos (al igual que los nombres de flujos y terminadores) deben provenir de un vocabulario que tenga algn significado para el usuario. Esto suceder de manera muy natural si el DFD se dibuja como resultado de una serie de entrevistas con los usuarios y si el analista tiene algn entendimiento mnimo de la materia de aplicacin. Recuerde: Debe tener en cuenta dos precauciones: Evitar en lo posible el uso de abreviaturas y acrnimos especficos con los que estn familiarizados los clientes (Ej. Consigue copia de la forma 107, forma rosada y se la manda a Jos una vez llena). Una buena forma de evitarlo es elegir (como LLENAR) y objetos (como FORMA 107) que tendra sentido para alguien que trabaje en la misma industria, pero en una organizacin diferente. Si el DFD lo dibuja alguien con conocimientos en programacin habr tendencia a utilizar terminologa orientada a la programacin, tal como RUTINA, PROCEDIMIENTO, FUNCION, aunque muchos trminos no tienen significado para el usuario. Evite usarlos a menos que el usuario los maneje. Numerar los procesos. Es una buena forma de referirse a los procesos de un DFD. No importa como se haga esta numeracin, de izquierda a derecha, de arriba abajo, mientras haya constancia en la forma de aplicar los nmeros. Lo que deber tener en cuenta es que para algunos lectores del DFD la numeracin implicar secuencia, podra preguntarle la burbuja 1 sucede primero y luego la 2?. Esto no es as en absoluto, el modelo de DFD es una red de procesos
75
asincrnicos que se intercomunican; representan la manera en que en realidad muchos sistemas operan. Alguna secuencia podra implicarse por la presencia por la presencia o secuencia de datos (Ej. Puede resultar que la burbuja 2 no pueda realizar su funcin hasta que no reciba datos de la burbuja1) pero el esquema de numeracin no tiene nada que ver con eso. Entonces, para que numerar los procesos; primero para poder referirnos en una discusin a una burbuja por su nmero en vez de por su nombre. En segundo lugar, y ms importante an, los nmeros se convierten en base para la numeracin jerrquica cuando se introduzcan diagramas de flujos por niveles. RECUERDE: REDIBUJAR EL DFD TANTAS VECES COMO SEA NECESARIO ESTTICAMENTE. En un proyecto real de anlisis de sistema, el DFD se dibujar tantas veces como se necesite antes de: ser tcnicamente correcto, ser aceptable para el usuario, estar lo suficientemente bien dibujado como para que no embarazoso mostrarlo a la direccin de la organizacin. Qu hace estticamente agradable un DFD? Tamao y forma de las burbujas, procure que estas sean similares en tamaos para no crear confusiones acerca de importancia de un proceso en el proyecto. Otras organizaciones preferirn valos en vez de crculos. Flujos Curvos vs. Rectos, sera lo ideal conocer que opcin prefiere el observador; para muchos ser lo mismo para otros no, lo mismo sucede con las flechas cruzadas. Recuerde: Evitar los DFD demasiado complejos. El propsito de un DFD es modelar de manera precisa las funciones que deber llevar a cabo un sistema y las interacciones entre ellas. Otro propsito de este es ser ledo y comprendido, no slo por quien construye el modelo sino tambin por los usuarios que participan. Entonces el diagrama deber: ser fcilmente entendido, fcilmente asimilado y placentero a la vista. Una regla importante a tener en cuenta es la de no crear DFD con demasiados procesos, flujos, almacenes y terminadores. Por lo general no debiera haber ms de media docena de procesos, flujos, almacenes y terminadores relacionados en un mismo diagrama. Otra regla dice que el DFD deber caber fcilmente en una hoja normal. Recuerde: Asegurarse de que el DFD sea internamente consistente y que tambin lo sea con cualquier DFD relacionado con l. Recuerde: Las principales reglas para asegurar la consistencia de un DFD son: Evite sumideros infinitos, burbujas que tienen entradas pero no salidas. Evite burbujas de generacin espontnea, que tienen salidas sin tener entradas; son generalmente errneas. Cuidado con flujos y procesos no etiquetados, suele indicar falta de esmero; pero peor an confusin respecto a la informacin que contienen. Cuidado con almacenes de solo lectura o solo escritura, esta regla es similar a la de los procesos de solo entradas o solo salidas, los almacenes comunes deben tener tanto entradas como salidas. La nica excepcin son los almacenes externos que sirve de interfaz entre el sistema y algn terminador externo.
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
76
PROGRAMA DE CALIDAD UDABOL DIF 006 SISTEMAS DE INFORMACIN Recuerde: Los Sistemas de Informacin (SI) y las Tecnologas de Informacin (TI) han cambiado la forma en que operan las organizaciones actuales. A travs de su uso se logran importantes mejoras, pues automatizan los procesos operativos, suministran una plataforma de informacin necesaria para la toma de decisiones y, lo ms importante, su implantacin logra ventajas competitivas o reducir la ventaja de los rivales. Las Tecnologas de la Informacin han sido conceptualizadas como la integracin y convergencia de la computacin, las telecomunicaciones y la tcnica para el procesamiento de datos, donde sus principales componentes son: el factor humano, los contenidos de la informacin, el equipamiento, la infraestructura, el software y los mecanismos de intercambio de informacin, los elementos de poltica y regulaciones, adems de los recursos financieros. Los componentes anteriores conforman los protagonistas del desarrollo informtico en una sociedad, tanto para su desarrollo como para su aplicacin, adems se reconoce que las tecnologas de la informacin constituyen el ncleo central de una transformacin multidimensional que experimenta la economa y la sociedad; de aqu lo importante que es el estudio y dominio de las influencias que tal transformacin impone al ser humano como ente social, ya que tiende a modificar no slo sus hbitos y patrones de conducta, sino, incluso, su forma de pensar. Dentro de las tecnologas de la informacin tambin debemos contemplar algunos conceptos y/o metodologas que merecen estar clasificadas como de alto impacto, ya sea para nuestra organizacin, el individuo o la sociedad misma. LA INFORMACIN COMO RECURSO DE LAS ORGANIZACIONES. Desde hace ya algunos aos las organizaciones han reconocido la importancia de administrar los principales recursos como la mano de obra y las materias primas. Recuerde: La informacin se ha colocado en un buen lugar como uno de los principales recursos que poseen las empresas actualmente. Los entes que se encargan de las tomas de decisiones han comenzado a comprender que la informacin no es slo un subproducto de la conduccin empresarial, sino que a la vez alimenta a los negocios y puede ser uno de los tantos factores crticos para la determinacin del xito o fracaso de stos. Si deseamos maximizar la utilidad que posee nuestra informacin, el negocio la debe manejar de forma correcta y eficiente, tal y cmo se manejan los dems recursos existentes. Los administradores deben comprender de manera general que hay costos asociados con la produccin, distribucin, seguridad, almacenamiento y recuperacin de toda la informacin que es manejada en la organizacin. Aunque la informacin se encuentra a nuestro alrededor, debemos saber que sta no es gratis, y su uso es estrictamente estratgico para posicionar de forma ventajosa la empresa dentro de un negocio. La fcil disponibilidad que poseen las computadoras y las tecnologas de informacin en general, han creado una revolucin informtica en la sociedad y de forma particular en los negocios. El manejo de informacin generada por computadora difiere en forma significativa del manejo de datos producidos manualmente. QU ES UN SISTEMA DE INFORMACIN? Un Sistema de Informacin es un conjunto de elementos que interactan entre s con el fin de apoyar las actividades de una empresa o negocio. En un sentido amplio, un sistema de informacin no necesariamente incluye equipo electrnico (hardware). Sin embargo en la prctica se utiliza como sinnimo de sistema de informacin computarizado. Los elementos que interactan entre s son: el equipo computacional, el recurso humano, los datos o informacin fuente, programas ejecutados por las computadoras, las telecomunicaciones y los procedimientos de polticas y reglas de operacin.
77
Recuerde: Un Sistema de Informacin realiza cuatro actividades bsicas: Entrada de informacin: proceso en el cual el sistema toma los datos que requiere para procesar la informacin, por medio de estaciones de trabajo, teclado, diskettes, cintas magnticas, cdigo de barras, etc. Almacenamiento de informacin: es una de las actividades ms importantes que tiene una computadora, ya que a travs de esta propiedad el sistema puede recordar la informacin guardad en la sesin o proceso anterior. Procesamiento de la informacin: esta caracterstica de los sistemas permite la transformacin de los datos fuente en informacin que puede ser utilizada para la toma de decisiones, lo que hace posible, entre otras cosas, que un tomador de decisiones genere una proyeccin financiera a partir de los datos que contiene un estado de resultados o un balance general en un ao base. Salida de informacin: es la capacidad de un SI para sacar la informacin procesada o bien datos de entrada al exterior. Las unidades tpicas de salida son las impresoras, graficadores, cintas magnticas, diskettes, la voz, etc. TIPOS Y USOS DE LOS SISTEMAS DE INFORMACIN. Durante los prximos aos, los sistemas de informacin cumplirn los siguientes objetivos: Automatizar los procesos operativos. Recuerde: Proporcionar informacin de apoyo a la toma de decisiones. Recuerde: Lograr ventajas competitivas a travs de su implantacin y uso. Con frecuencia, los sistemas de informacin que logran la automatizacin de procesos operativos dentro de una organizacin son llamados Sistemas Transaccionales, ya que su funcin principal consiste en procesar transacciones tales como pagos, cobros, plizas, planillas, entradas, salidas. Por otra parte, los sistemas de informacin que apoyan el proceso de toma de decisiones son los sistemas de apoyo a la toma de decisiones (DSS, por sus siglas en ingls Decisin Supporting System). El tercer tipo de sistemas, de acuerdo con su uso u objetivos que cumplen, es de los Sistemas Estratgicos, los cuales se desarrollan en las organizaciones con el fin de lograr las ventajas competitivas, a travs del uso de la Tecnologa de Informacin (TI). IMPORTANCIA DE LOS SISTEMAS DE INFORMACIN Cuando muchas personas se preguntan por qu estudiar sobre los sistemas de informacin, es lo mismo que preguntar por qu debera estudiar alguien contabilidad, finanzas, gestin de operaciones, marketing, administracin de recursos humanos o cualquier otra funcin empresarial importante. Lo que si les puedo asegurar es que muchas empresas y organizaciones tienen xitos en sus objetivos por la implantacin y uso de los Sistemas de Informacin. De esta forma, constituyen un campo esencial de estudio en administracin y gerencia de empresas. Es por esta razn que todos los profesionales en el rea de Administracin de Empresas deberan o ms bien deben, tomar un curso de sistemas de informacin. Por otro lado es importante tener una comprensin bsica de los sistemas de informacin para entender cualquier otra rea funcional en la empresa, por eso es importante tambin, tener una cultura informtica en nuestras organizaciones que permitan y den las condiciones necesarias para que los sistemas de informacin logren los objetivos citados anteriormente. Muchas veces las organizaciones no han entrado en la etapa de cambio haca la era de la informacin sin saber que es un riesgo muy grande de fracaso debido a las amenazas del mercado y su incapacidad de competir, por ejemplo, las TI que se basan en Internet se estn convirtiendo rpidamente en un ingrediente necesario par el xito empresarial en el entorno global y dinmico de hoy.
78
Por lo tanto, la administracin apropiada de los sistemas de informacin es un desafo importante para los gerentes. As la funcin de los SI representa: Un rea funcional principal dentro de la empresa, que es tan importante para el xito empresarial como las funciones de contabilidad, finanzas, administracin de operaciones, marketing, y administracin de recursos humanos. Una colaboracin importante para le eficiencia operacional, la productividad y la moral del empleado, y el servicio y satisfaccin del cliente. Una fuente importante de informacin y respaldo importante para la toma de decisiones efectivas por parte de los gerentes. Un ingrediente importante para el desarrollo de productos y servicios competitivos que den a las organizaciones una ventaja estratgica en el mercado global. Recuerde: Una oportunidad profesional esencial, dinmica y retadora para millones de hombres y mujeres. UNA SOCIEDAD DE INFORMACION GLOBAL Estamos viviendo en una sociedad de informacin global emergente, con una economa global que depende cada vez ms de la creacin, la administracin y la distribucin de la informacin a travs de redes globales como Internet. Muchas empresas estn en proceso de globalizacin; es decir, se estn convirtiendo en empresas globales interconectadas en red. Por ejemplo, las empresas se estn expandiendo a mercados globales para sus productos y servicios, utilizando instalaciones de producciones globales para fabricar o ensamblar productos, reuniendo dinero en mercados de capitales globales, formando alianzas con socios globales y luchando con competidores globales pro clientes de todo el mundo. El manejo y la realizacin de estos cambios estratgicos seran imposibles sin Internet, Intranets[2] y otras redes globales de computacin y de telecomunicaciones que constituyen un sistema nervioso central de las empresas globales de hoy. Las personas de muchas naciones ya no viven en sociedades agrcolas, compuestas principalmente de agricultores, o incluso sociedades industriales, donde la mayor parte de la fuerza laboral se compone de trabajadores de fbrica. En cambio, en muchas naciones gran parte de la fuerza laboral est constituida por personas que se ocupan en labores de prestacin de servicios o trabajadores del conocimiento, es decir, personas que se dedican la mayor parte de su tiempo a la comunicacin y colaboracin en equipos y grupos de trabajo, y a la creacin, uso y distribucin de la informacin. ESTRATEGIAS COMPETITIVAS CON LA TI Con frecuencia, el uso de la tecnologa de informacin para la globalizacin y la reingeniera de procesos empresariales da como resultado el desarrollo de sistemas de informacin que ayudan a una empresa a darle ventaja competitiva en el mercado, utilizndolos para desarrollar productos, servicios, procesos y capacidades que dan a una empresa una ventaja estratgica sobre las fuerzas competitivas que enfrenta una empresa. Estrategias de costo, por ejemplo, utilizando sistemas de manufactura asistidos por computadora para reducir los costos de produccin, o crear sitios Web en Internet para comercio electrnico (e-business), con el fin de reducir los costos del marketing. Estrategias de diferenciacin, como desarrollar maneras de utilizar la tecnologa de informacin para diferenciar productos o servicios de una empresa, de los de sus competidores, de manera que los clientes perciban los productos o servicios como poseedores de atributos o beneficios nicos. Por ejemplo, suministrar servicios rpidos y completos de soporte al cliente por medio de un sitio Web en Internet, o utilizar sistemas de marketing como objetivo para ofrecer a clientes individuales los productos y servicios que le atraen. Recuerde: Es necesario leer muy atentamente el presente DIF para realizar el trabajo correctamente. . PROGRAMA DE CALIDAD UDABOL DIF 007
79
METODOLOGA DE DESARROLLO EMPLEADA El mtodo de desarrollo aplicado es el de Prototipos Evolutivos con implementacin de requerimientos incrementales, en donde se definen 2 estados etapas bsicas, adems cada una tiene subprocesos de los cuales en la primera etapa se incluye una activa participacin del usuario final. Las dos etapas fundamentales son: Etapa software versin inestable: Es la etapa en la cual el software prototipo se encuentra en el estado de captura, diseo e implementacin de los requerimientos del usuario final. Estos estados son auditados a travs de las pruebas del prototipo y refinacin del mismo. En sta etapa el prototipo del software no posee una total garanta de inexistencia de fallas o cualidades de calidad incorporada, por lo que su ejecucin, para produccin, es muy riesgosa. Es importante destacar la activa participacin del usuario final en las etapas de anlisis de requerimientos, diseo y pruebas de prototipo, ya que l entrega informacin muy til con respecto a los resultados de cada estado en la etapa. Recuerde: Una vez que sta etapa es completada, se pasa, mediante el congelamiento del cdigo, a la etapa de prototipos donde la versin del software es estable. Etapa software versin estable: Es la segunda etapa en el ciclo general de desarrollo de software. En sta etapa se trabaja con el cdigo fuente del proyecto de software congelado, es decir, no se permite a los desarrolladores agregar nuevas caractersticas funcionales. Slo es posible solucionar desperfectos o fallas y optimizar algoritmos de ejecucin. Una vez que se halla solucionado todas las fallas conocidas y optimizado el funcionamiento del software, es entregado al usuario final.
As el proceso es iniciado con la determinacin de requerimientos, seguido de l diseo del prototipo, luego que el diseo sea efectivo, se procede a implementar las partes ms crticas de modelo diseado que posteriormente son presentadas al usuario para ser refinadas. Una vez que son aprobadas por el usuario el proceso se inicia nuevamente con el anlisis de nuevos requerimientos y asi sucesivamente hasta que el usuario complete todos sus requerimientos inicialmente descritos y otros requerimientos que salieron a la luz mientras se interactuaba con el software.
80
Una vez que este ciclo se ha completado, se procede a congelar el cdigo, es decir, no se permite agregar nuevas cualidades ni funciones, ahora es necesario slo preocuparse de eliminar fallas y optimizar algoritmos de ejecucin, para alcanzar los requerimientos de rendimiento determinados.
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
81

SISTEMAS DE SOPORTE PARA LA TOMA DE DECISIONES (DSS: DECISION SUPPORT SYSTEMS) Caractersticas

Interactividad. Interactuar en forma amigable y con el cargado de tomar decisiones. Tipo de decisiones. Apoya el proceso de toma de decisiones estructuradas y no estructuradas. Frecuencia de uso. Tiene una utilizacin frecuente por parte de la administracin. Variedad de usuario. Puede emplearse por usuarios de diferentes reas funcionales. Flexibilidad. Permite acoplarse a una variedad determinada de estilos administrativos participativos. Desarrollo que el usuario desarrolle de manera directa modelos de decisin sin la participacin operativa de profesionales en informtica. Interaccin ambiental. Permite la posibilidad de interactuar con informacin externa como parte de los modelos de decisin. Comunicacin nter organizacional. Facilita la comunicacin de informacin relevante de los niveles altos a los niveles operativos y viceversa, a travs de grficas. Acceso a bases de datos. Tiene la capacidad de acceder informacin de las bases de datos corporativas. Simplicidad. Simple y fcil de aprender y utilizar por el usuario final.
Recuerde: DSS integran en su mayora un conjunto de modelos que apoyan las diferentes decisiones a las que se enfrenta el tomador de decisiones. Recuerde: Ventajas del uso de los DSS.

Menores costos. Disponibilidad de una gran variedad de herramientas en el mercado que operan en el ambiente de microcomputadoras. Muy baja dependencia de personas que se encuentran fuera del control de tomador de decisiones.
Recuerde: Desventajas pueden ser:

Falta de integridad y consolidacin en la administracin de la informacin. Problemas de seguridad de la informacin. Perdida del control administrativa por parte del rea de informtica.
Las diferentes opciones para la implantacin de los DSS

Implantacin aislada en microcomputadoras. Implantacin en microcomputadoras interconectadas y que constituyen una red local. Microcomputadoras conectadas a mini computadoras o servidores.
MDULOS FUNCIONALES QUE INTEGRAN UN DSS. Una de las caractersticas que poseen los DSS es la facilidad de que un usuario, sin tener conocimientos amplios sobre sistemas computacionales, pueda desarrollar sus propios modelos de decisin. Estos modelos son construidos con la ayuda de las herramientas, que en trminos generales se clasifican en herramientas de hardware y de software.
82
MANEJO DE MODELOS. Permite al usuario utilizar modelos clsicos, que se encuentran desarrollados y disponibles, formando la base de modelos. Pueden incluir:

Inventarios Control de proyectos Programacin lineal Simulacin Colas Anlisis estadsticos Planeacin financiera y generacin de esencias
MANEJO Y ADMINISTRACIN DE DATOS. Recuerde: Incluye funciones tales como:

Acceso a las bases de datos corporativos Generacin de informacin privada en bases de datos locales. Manipulacin de la informacin a travs de tcnicas de manejo de informacin.
DESARROLLO DE APLICACIONES. La mayora de los DSS permite a los usuarios desarrollar sus propios modelos de decisin. En este sentido, el usuario disea sus propios formatos de entrada y salida, as como la estructura de almacenamiento y las funciones de procesamiento, tal forma que el sistema puede evolucionar de manera permanente, a travs de los cambios. Prototipo, es diferente al proceso tradicional de desarrollo de un sistema tradicional de desarrollo de un sistema transaccional tpico. Recuerde: Las Aplicaciones desechables, es decir, modelos de decisin que fueron desarrollados en tiempo muy corto, para apoyar una decisin en particular. INTERFACES GRFICAS, REPORTES Y CONSULTAS. Facilidad para explorar la informacin a travs de graficas de alta calidad y reportes que se disean y obtienen en intervalos cortos de tiempo, la disponibilidad de lenguajes de muy alto nivel para facilitar la consulta de informacin que contienen las bases de datos.
U N
I V E R
S I D A D
D E
Q U
I N O
O L
I V
I A
83

s5 - Analisis - de - Sistemas - I PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

s5 - Analisis - de - Sistemas - I PDF

Uploaded by

Copyright:

Available Formats

FACULTAD DE CIENCIAS Y TECNOLOGIA

RED NACIONAL UNIVERSITARIA

SYLLABUS Facultad de Ciencias y Tecnologa

QUINTO SEMESTRE ANLISIS DE SISTEMAS I

Syllabus elaborado por: Ing. Reynaldo Einar Zabaleta Rioja

FACULTAD DE CIENCIAS Y TECNOLOGIA

VISIN DE LA UNIVERSIDAD Ser la Universidad lder en calidad educativa.

FACULTAD DE CIENCIAS Y TECNOLOGIA

ANLISIS DE SISTEMAS I CMP 316 CMP 228 80 Horas 60 Horas 20 Horas 8

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

EVALUACION FINAL PROMEDIO PARCIAL 1, 2 Y FINAL

FACULTAD DE CIENCIAS Y TECNOLOGIA

VI. PLAN CALENDARIO

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

PROGRAMA DE CONTROL DE CALIDAD

No. DE PROCEDIMIENTO: APRO 07

ELABOR: Ing. Yubitza Adela Quintanilla Guzmn

CDIGO: CMP 316

OBSERVACIONES: Asignatura Anlisis de Sistemas I, Carrera Ingeniera de Sistemas, Unidad I, Tema 1

FECHA DE DIFUSIN: Marzo 2011

FECHA DE ENTREGA: Marzo 2011

INTRODUCCION AL ANLISIS DE SISTEMAS

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

PROGRAMA DE CONTROL DE CALIDAD

FACULTAD DE CIENCIAS Y TECNOLOGIA

No. DE PROCEDIMIENTO: APRO 07

ELABOR: Ing. Yubitza Adela Quintanilla Guzmn

CDIGO: CMP 316

OBSERVACIONES: Asignatura Anlisis de Sistemas I, Carrera Ingeniera de Sistemas, Unidad I, Tema 2

FECHA DE DIFUSIN: Marzo 2011

FECHA DE ENTREGA: Marzo 2011

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

Las desventajas de este modelo son :

FACULTAD DE CIENCIAS Y TECNOLOGIA

Y las desventajas de este prototipo son:

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

PROGRAMA DE CONTROL DE CALIDAD

No. DE PROCEDIMIENTO: APRO 07

CDIGO: CMP 316

FECHA DE DIFUSIN: Abril 2011

FECHA DE ENTREGA: Abril 2011

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA

FACULTAD DE CIENCIAS Y TECNOLOGIA