Sei sulla pagina 1di 41

1

1.1. Introduccin

Las enfermedades provocadas por alimentos contaminados constituyen un importante problema sanitario, quizs el ms difundido en el mundo.

Bolivia no se escapa de tal situacin, de acuerdo con los reportes del Ministerio de Salud y Previsin Social, relacionados con las altas tazas de morbilidad de las enfermedades diarreicas, una cantidad considerable de los casos de diarrea aguda son causados por alimentos contaminados por bacterias, esto se debe a las precarias condiciones de saneamiento bsico, el bajo nivel educativo de la poblacin en materia de inocuidad de alimentos, la proliferacin de ventas callejeras o ambulantes, el crecimiento de las industrias, el bajo control sanitario por parte del estado y la falta de una legislacin moderna y proactiva, entre otros factores(1).

Es por eso que se cre el Sistema Integrado de Inocuidad Alimentara SIIA, que tiene alcance nacional e involucra a todas las entidades pblicas y privadas con jurisdiccin fiscalizadora de la inocuidad de los alimentos, incluyendo a los consumidores, en el marco de la legislacin vigente.

Entre los componentes del SIIA tenemos: Inspeccin, Certificacin y Registros


(2)

responsabilidades a cargo del departamento de Salud Ambiental,

dependiente de las SEDES de Bolivia; cuya principal labor es la emisin del carnet de manipulador de alimentos a los trabajadores de la produccin primaria y de las

(1) (2)

Programa para el Desarrollo del Sistema de Desarrollo de Inocuidad Alimentaria-febrero de 2006 Programa para el Desarrollo del Sistema de Desarrollo de Inocuidad Alimentaria-febrero de 2006

industrias, siendo obligatorio los chequeos, anlisis y capacitacin de los manipuladores adems se otorga un certificado sanitario a servicios de alimentacin y locales de expendio de alimentos y bebidas.

En Tarija existen aproximadamente 923 vendedores ambulantes que cuentan con carnet sanitario y 350 locales de expendio de alimentos que cuentan con el certificado sanitario, por lo tanto la informacin generada dentro del departamento de salud ambiental es excesiva lo cual torna dificultoso llevar un control efectivo, asimismo el registro de los mismos es informal y redundante, puesto que se registran en una hoja de Microsoft Excel, en el libro de recaudaciones y en el libro de certificados o en el de carnets.

Es as como se evidencia la necesidad de la creacin de un sistema informtico, que cubra el flujo de informacin que se genera, de esta manera se lograr eliminar la redundancia en el registro de los certificados y carnets, al mismo tiempo se podr clasificar, organizar y formalizar la informacin para obtener la misma de manera rpida, fcil y oportuna, beneficiando a los solicitantes con una gestin mas rpida y segura, en donde los usuarios puedan acceder a la informacin mediante una red LAN de acuerdo a sus requerimientos.

1.2. Antecedentes La tecnologa debe estar al servicio del usuario; a travs de ella se hace un mejoramiento de la capacidad decisoria del personal, facilita el diseo de los sistemas de informacin para la calidad del servicio, as se maneja ms informacin y menos papeles. Actualmente, el manejo de la informacin de modo eficiente constituye una de las principales preocupaciones dentro de cualquier organizacin, sea esta de origen pblico o privado, por lo que se hace necesario manejarla y emplearla con mucho criterio, ya que de ello podra depender, en gran medida, el xito o fracaso de la

misma. La sociedad de la informacin ha dejado de ser slo una idea y se est convirtiendo en una realidad cada vez ms clara, tiene alcance mundial e involucra a todas las entidades pblicas y privadas. A pesar de existir estos esfuerzos por manejar de manera eficiente la informacin, el SEDES no cuenta con sistemas ajustados a sus necesidades, por el momento solo cuenta con sistemas generales como el Epi Info y el SINCOM. El Epi Info es un programa de dominio pblico diseado por el Centro para el Control de Enfermedades de Atlanta (CDC) de especial utilidad para la Salud Pblica. Tiene un sistema fcil para construir bases de datos, analizarlos con las estadsticas de uso bsico en epidemiologa y representarlos con grficos y mapas, a pesar de las capacidades de este sistema, ste no es manejado ni explotado adecuadamente. Por otro lado, el SINCOM (Sistema Integrado de Contabilidad Municipal), desarrollado en Bolivia, es manejado por la unidad de Administracin pero no cuenta con la asesora tcnica necesaria. Toda la informacin que se manipula dentro del departamento de salud ambiental esta distribuida en diferentes oficinas, encontrndose disgregada puesto que no se comparte ningn tipo de informacin entre los equipos de las mismas. El sistema se encargar del manejo de grandes volmenes de informacin y de compartir la misma de acuerdo a los requerimientos del los usuarios, pues el incremento del comercio en la ciudad de Tarija principalmente el de alimentos, constituye un problema que implica una variada gama de aspectos que van desde aquellos referidos a la salud pblica hasta los de empleo e ingresos que la actividad genera(3); es por este notable incremento que se torna arduo llevar un control efectivo de los expendedores de alimentos.
_________________________________________ (3) (4)

Plan Departamental desalad Ambiental Tarija 2005-2009 Programa para el Desarrollo del Sistema de Desarrollo de Inocuidad Alimentaria-febrero de 2006

El sistema tambin brindar diferentes tipos de reportes, los cuales apoyarn al departamento de salud ambiental en la tarea de inspeccionar los expendios, pues en efecto, las condiciones actuales de manipulacin de alimentos y bebidas, reflejadas en malas o psimas condiciones sanitarias de toda la cadena alimentaria (produccin, distribucin, almacenamiento, expendio y consumo) han expuesto a la poblacin de la ciudad a un elevado riesgo de ETAs (principalmente salmonelosis, cisticercosis, fiebre tifoidea, shigelosis y otras) (4). Debido a la falta de claridad en la legislacin alimentaria y la ausencia de apoyo poltico para ordenar el sector, no se lleg a la coordinacin interinstitucional, as mismo los escasos recursos en infraestructura y recursos humanos influyeron negativamente para optimizar el programa, es por esta situacin que SEDES-Tarija no cuenta con los recursos econmicos suficientes para implementar en sus diferentes programas sistemas informticos que ayuden con el procesamiento de la informacin de manera automtica. De todo lo mencionado anteriormente es que naci nuestro inters por desarrollar un sistema que satisfaga estas necesidades de informacin, nosotros como egresados de informtica, a tiempo de cumplir con los requisitos de titulacin, desarrollaremos este sistema como aporte a la sociedad y a la ciencia. 1.3. Planteamiento del Problema El problema identificado de acuerdo al mtodo Isac (ver Anexo1) es el siguiente: Los datos que se manejan en el departamento de Salud Ambiental son excesivos, su tratamiento es semiautomatizado, esto ocasiona redundancia innecesaria de los mismos, tornando dificultoso obtener la informacin de manera oportuna; dichos datos se refieren a datos sanitarios, datos administrativos y datos financieros.

1.4. Objetivos. 1.4.1. Objetivo General Desarrollar un sistema de informacin automatizado, para el Departamento de Salud Ambiental, dependiente del SEDES Tarija; clasificando, organizando y compartiendo los datos generados dentro de sta Unidad, con el propsito de brindar informacin oportuna a sus usuarios. 1.4.2. Objetivos Especficos Efectuar el anlisis de requerimientos para identificar las necesidades de informacin dentro del departamento de Salud Ambiental, mediante la metodologa Isac. Aplicar la metodologa RUP para el desarrollo del sistema de informacin. Apoyarse en el uso de herramientas CASE para la aplicacin de RUP. Proporcionar una interfaz amigable para el usuario. Disear una base de datos en la que se encuentre seleccionada, organizada y clasificada la informacin que se genera dentro del departamento de Salud Ambiental. Realizar las diferentes pruebas y manejar los resultados de cada prueba sistemticamente Implantar el sistema de informacin segn el modelo tecnolgico propuesto.

1.5. Justificacin 1.5.1. Justificacin Social. Con un sistema capaz de automatizar la clasificacin y organizacin de la informacin generada dentro de la Unidad de Salud Ambiental con respecto a la emisin de carnets y certificados se podr ayudar en la toma de decisiones, permitiendo de esta manera atender rpida y organizadamente a las personas que acuden a la misma. Al compartir informacin La Unidad de Salud Ambiental podr contar con una herramienta para optimizar el trabajo que se desarrolla dentro de esta, beneficiando directamente a la institucin y a la sociedad en su conjunto. Es importante que los diferentes organismos gubernamentales y no gubernamentales sean capaces de adaptar las nuevas tecnologas a los diferentes requerimientos con los que cuentan para poder desempear un trabajo ms eficiente. Lamentablemente son muy pocos los organismos gubernamentales que estn adaptando nuevos sistemas informticos para una mejor manipulacin de los datos, un claro ejemplo de esta deficiencia es el departamento de Salud Ambiental de Tarija que a pesar de manipular gran cantidad de informacin cuentan con herramientas precarias para su manipulacin lo cual ocasiona que la informacin no se encuentre disponible y se torne dificultoso el control de los expendedores de alimentos.

1.5.2. Justificacin Acadmica. Mediante el desarrollo de ste sistema se incursionar en nuevas tecnologas y se llevar a la prctica una serie de tcnicas y metodologas adquiridas durante nuestro paso por las aulas de la Universidad Juan Misael Saracho.

Fueron varias las razones que nos llevaron a escoger ste tema, donde el entusiasmo por un sistema de esta naturaleza nos encamin a reflexionar respecto a la forma en que an se manipulan los datos en nuestro departamento, puesto que a pesar de que hay instituciones que manejan gran cantidad de informacin todava no cuentan con sistemas automatizados para el tratamiento de la misma. Con la realizacin de un sistema de esta naturaleza se hace un trabajo cientfico que al mismo tiempo es beneficioso tanto para el personal a cargo del departamento de Salud Ambiental como para la ciudadana. 1.5.3. Justificacin Tecnolgica. Para la implementacin de ste sistema de informacin, el departamento cuenta con 2 computadoras Pentium III de 733 Mhz y 256 MB de Ram y una Pentium IV de 3 Ghz y 512 Ram que soportan las tecnologas a ser empleadas para la implementacin del sistema de informacin y la red. Browser Web Server Servidor Aplicacin
DBMS HTTP

Contenido

Sistema Heredado

1.5.4. Justificacin Econmica. El desarrollo de este sistema no conlleva a grandes gastos, puesto que no es necesario abrir una oficina, contar con personal adicional para el anlisis y diseo ni comprar material, pagar licencias, software o hardware. El sistema ser desarrollado de manera gratuita para la Unidad de Salud Ambiental, en equipos que ya poseemos.

1.5.5. Justificacin Operativa. La realizacin de este sistema se presentar con una interfaz compresible para los usuarios. ste proyecto contribuir al ingreso del proceso de modernizacin, brindando informacin oportuna, confiable y de fcil acceso logrando transparentar la labor que desempea la Unidad de Salud Ambiental y permitindole desempear sus funciones de manera eficaz. 1.6. Alcances y Limitaciones 1.6.1 Alcances De acuerdo a las necesidades encontradas en el departamento de salud ambiental el rea de estudio del presente trabajo contemplar: Mdulo de gestin sanitaria: Administracin de carnets sanitarios. Administracin de certificados sanitarios. Administracin de autorizaciones sanitarias. Administracin de historias clnicas. Mdulo de gestin administrativa: Administracin de zonas. Administracin de usuarios. Administracin de categoras. Mdulo de gestin financiera: Recaudaciones por concepto de carnets sanitarios Recaudaciones por concepto de certificados sanitarios Recaudaciones por concepto de autorizaciones sanitarias Mdulo de reportes: Reportes de carnets y certificados sanitarios emitidos. Reportes de carnets y certificados sanitarios vencidos. Reportes de recaudaciones.

Mdulo para publicacin de informacin sanitaria va Web. 1.6.2. Limitaciones. El sistema estar centrado en el rea de inocuidad alimentaria del departamento de Tarija. No ser un sistema contable, solo registrar ingresos. El usuario no podr modificar ningn dato va Web solo podr realizar consultas. 1.7. Responsabilidades A continuacin se presentan las responsabilidades, de cada uno de los integrantes del presente trabajo, acuerdo a la las tareas de la metodologa RUP. Integrante Evelyn Vacaflor Bentez

Responsabilidad Determinar casos de uso y actores Construir diagrama de actividades que represente el modelo del negocio Planificar Implementacin Estudiar Herramientas y Tecnologas Planificacin y Generacin del producto final Documentacin y Capacitacin Planificar y Evaluar la Iteracin

Isaac Lange Aguilar

Tabla 1. Responsabilidades (fuente: Elaboracin Propia)

1.8. Explicacin de las Alternativas de Solucin Propuestas De acuerdo a la metodologa Isac, utilizada para el Anlisis del Cambio (ver Anexo1), la mejor alternativa de solucin para lograr una optimizacin en la manipulacin de los datos dentro del Departamento de Salud Ambiental es el paquete 3 debido a que ser desarrollado con la finalidad de implantar un sistema capaz de

10

trabajar en red con el objeto de optimizar los recursos y emular el proceso de un sistema de cmputo nico para clasificar y organizar la informacin generada dentro de este departamento, que al mismo tiempo ayude en la toma de decisiones mediante la disponibilidad de la informacin, permitiendo de esta manera la optimizacin de las actividades que se desempean dentro del departamento de Salud Ambiental; adems de atender rpida y organizadamente a las personas que acuden a la misma. Con este paquete se lograr cumplir con los objetivos planteados. 1.9. Cronograma Con el fin de dar una estimacin del tiempo que llevar terminar cada tarea o actividad y asegurar de que el proyecto se vaya desarrollando de acuerdo al plan previsto, es importante contar con una metodologa de seguimiento que facilite el control y permita establecer la relacin de cada una de las etapas con el resto de las existentes. De esta manera ser ms fcil descubrir qu etapa est atrasada y afectando a las siguientes y con ello al conjunto del trabajo. A continuacin se presenta un calendario de las principales tareas del proyecto de acuerdo a la metodologa RUP. Esto no quita la posibilidad de su posterior refinamiento y cambios.

11

A c t i d a d A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14 A15 A16 A17 A18 A19
S1

Inicio
Iter 1 S2 S3 Iter 2 S4 S5

Elaboracin
Iter 1 S6 S7 Iter 2 S8 S9

Construccin
Iter 1 S10 S11 Iter 2 S12

Transicin
Iter1 S13 Iter 2 S14

Tabla 2. Cronograma (fuente: Elaboracin Propia)

A: s:

Actividad Semana

Iter: Iteracin

12

A1: Entrevistas con el personal del Departamento de Salud Ambiental. A2: Analizar el alcance A3: Refinar el Problema A4: Elaborar la arquitectura de negocios A5: Determinar casos de uso y actores A6: Construir diagrama de actividades que represente el modelo del negocio A7: Construir prototipo de la arquitectura A8: Estudiar Herramientas y Tecnologas A9: Planificar Implementacin A10: Planificar Verificacin A11: Verificar A12: Evaluar Verificacin A13: Planificacin y Generacin del producto final A14: Documentacin y Capacitacin A15: Prototipos y Ejecutables Primarios A16: Monitorear el Proyecto A17: Planificar y Evaluar la Iteracin A18: Planificar el Proyecto A19: Evaluar y Ajustar el Plan del Proyecto

13

II. Marco Terico o de Referencia 2.1. Departamento de Salud Ambiental La salud ambiental es aquella parte de las ciencias ambientales que se ocupa de los riesgos y efectos que para la salud humana representan el medio que habita y donde trabaja, los cambios naturales o artificiales que ese lugar manifiesta y la contaminacin producida por el mismo hombre a ese medio (5). Visin Para el ao 2009, en un trabajo conjunto de las instituciones y la poblacin, con eficiente gestin intersectorial de la salud ambiental, los tarijeos habremos reducido los riesgos ambientales para la salud, tendremos ambientes mas limpios y saludables, que garanticen una mejor calidad de vida de las actuales y futuras generaciones que habiten el Departamento Misin El plan Departamental de Salud Ambiental se constituye en un modelo ordenador y articulador de las acciones presentes y futuras sobre las relaciones hombre ambiente, el control de los riesgos ambientales sobre la salud humana, la vigilancia y el seguimiento a los cambios en las determinantes ambientales y la evaluacin del impacto de los proyectos planteados. 2.1.1 rea Relacionada (Afectada) El presente trabajo est dirigido a la Unidad Regional de Epidemiologa del Servicio Departamental de Salud (SEDES), ms concretamente al departamento de Salud Ambiental; este sistema afectar directamente a el rea de inocuidad alimentaria e indirectamente a la Unidad Regional de Epidemiologa, Direccin Tcnica del Sedes y Prefectura del Departamento, puesto que los mismos podrn contar con informacin confiable.
(5)

Programa para el Desarrollo del Sistema de Desarrollo de Inocuidad Alimentaria-febrero de 2006

14

rea beneficiada con la implementacin

Figura 1. Organigrama (fuente: Secretara Tcnica de Planificacin del SEDES)

15

2.1.2. Estrategias del Departamento de Salud Ambiental. La situacin econmica, los riesgos de contaminacin alimenticia y los compromisos internacionales obligan al pas a aumentar el comercio de alimentos nacionales, basados en la confiabilidad y competitividad de los mismos. Por lo consiguiente es necesario contar con actividades y estrategias para poder disminuir el riego de la salud del consumidor y mejorar la calidad de produccin para la importacin y exportacin de los alimentos. Tanto las actividades y las estrategias sern debidamente coordinadas a nivel nacional departamental e institucional. Las estrategias planteadas por el Ministerio de Salud conjuntamente con las SEDES de todo el Pas son las siguientes: Capacitar y actualizar al personal tcnico del rea de alimentos, orientados a desempearse como elemento multiplicador. Dar mayor apoyo y prioridad a los programas educativos en el tema alimentario dirigidos a la poblacin, coordinando con los niveles operativos. Revisar, actualizar y adoptar normas para la produccin, transporte, almacenamiento, distribucin y otros temas relacionados con alimentos, acorde con normas internacionales, principalmente con las del Codex Alimentarius. Fortalecer la red nacional de laboratorios. Buscar y establecer medios econmicos para la sostenibilidad del programa. Mejorar el sistema de informacin desde los niveles operativos hacia los normativos y de los normativos a los niveles operativos. Dar asistencia tcnica y orientacin a los municipios. Supervisar y monitorear a niveles operativos en forma permanente a fin de mantener y mejorar el sistema de acuerdo a las necesidades regionales y locales. Fortalecer los programas municipales y evitar improvisaciones en las acciones

16

operativas. Crear mecanismos que incentiven al conocimiento y practicas de higiene de alimentos como ser ferias, concursos, kermesses y otros. Objetivos del Departamento de Salud Ambiental. Elevar el nivel de vida de la poblacin evitando enfermedades de origen alimentario y proporcionando alimentos seguros. Proteger la salud y los intereses econmicos del consumidor contra riesgos que implican los alimentos contaminados, adulterados o de escasa calidad e inocuidad, adems de los fraudes de comercio. Mejorar al comercio nacional e internacional de alimentos, elevando la calidad y seguridad de los alimentos producidos y distribuidos en el pas, aplicando mtodos de control de calidad de los alimentos reconocidos internacionalmente. Evitar perdidas econmicas por el manipuleo correcto de alimentos. Objetivos Especficos Contar con normas alimentarias acordes con los requerimientos nacionales e internacionales, dentro el marco del CODEX ALIMENTARIUS, como parte de la legislacin alimentaria del pas. Mejorar los servicios de inspeccin dirigido a la calidad sanitaria de los alimentos, cubriendo el procesamiento o industrializacin. Asesoramiento y control de los alimentos en el rea de distribucin, expendio y consumo, mediante una buena coordinacin interinstitucional y el correcto ordenamiento de sector. Sistematizar la informacin y retroalimentacin del Departamento de Salud Ambiental. Asesorar en la elaboracin y desarrollo del programa de Control de Alimentos a todos los municipios.

17

Desarrollo del Programa del Departamento de Salud Ambiental Los objetivos mencionados anteriormente se los podr realizar mediante el siguiente programa: Revisin de la normativa Codex para que se adopten los aspectos de inocuidad con reglamento tcnico obligatorio. Los inspectores sanitarios del Ministerio de Salud podrn emitir citaciones para obtener el certificado o el carnet correspondiente, con una duracin mxima anual. Establecer de carcter obligatorio que las instancias departamentales y municipales posean el programa de control de alimentos, basado en el SIIA, adems de incorporarlos en los POA correspondientes. Las SEDES coordinaran las actividades de inspeccin de industrias y establecern 1 inspeccin cada dos aos a cada industria. El departamento de Salud Ambiental tendr una base de datos con el registro actualizado de las industrias, establecimientos de comercializacin, expendios y manipuladores. Las SEDES emitirn el carnet de manipulador de alimentos a los trabajadores de los establecimientos de comercializacin, expendio y consumo, siendo obligatorios los controles, anlisis y capacitacin de los manipuladores. El departamento de Salud Ambiental deber informar las actividades realizadas a las direcciones e instancias correspondientes cuando los mismos lo requieran. Se tendr una base de datos sobre los resultados de la vigilancia a nivel departamental.

18

2.2. Inocuidad Alimentaria El departamento de Inocuidad Alimentaria tiene como responsabilidad vigilar la calidad alimentaria de los alimentos, para proporcionar informacin oportuna y confiable de aquellos que ofrecen mayor riesgo epidemiolgico, conocer los diferentes grados de contaminacin y aplicar medidas de intervencin mediante la inspeccin sanitaria. Por lo tanto deber cumplir con las siguientes atribuciones(6): Conducir el sistema de control y supervisin de inocuidad de los alimentos en los tramos de supervisin y procesamiento del sector agropecuario en el comercio externo e interno. Certificar alimentos para el comercio externo e interno, facilitando el comercio nacional e internacional. Elaborar la normativa sobre inocuidad alimenticia en coordinacin con otras instituciones del Estado. Conducir el sistema nacional de control e inspeccin de industrias procesadoras e importadoras de alimentos destinados al consumo humano. Conducir las actividades relacionadas a la inocuidad Alimentaria en el mbito nacional. 2.2.1. reas de trabajo (7) Inspeccin y Control de Alimentos. Registro de Industrias Procesadoras e Importadoras de alimentos. Control de etiquetado. Control de seguimiento a mataderos.

19

Laboratorio de Anlisis de Residuos y Alimentos.

(6) (7)

Programa para el Desarrollo del Sistema de Desarrollo de Inocuidad Alimentaria-febrero de 2006 Programa para el Desarrollo del Sistema de Desarrollo de Inocuidad Alimentaria-febrero de 2006

2.3. Registro Sanitario El objetivo del registro sanitario es efectuar un control a las industrias alimenticias, a fin de que estas elaboren y provean productos alimenticios inicuos a la poblacin, de esta manera el productor de alimentos estar seguro de que sus productos estn acorde con las normativas de calidad, higiene y de manufacturacin, para que as el consumidor confi en que esos alimentos son garantizados. 2.4. Sistema de Informacin. Gran parte de nuestra sociedad se apoya en la tecnologa de sistemas de informacin, ya sea directa o indirectamente, para trabajar con Mayor inteligencia. Un sistema es un conjunto de componentes que interactan entre s para lograr un objetivo comn. Todo sistema organizacional depende en mayor o menor medida, de una entidad abstracta denominada sistema de informacin. Este sistema es el medio por el cual los datos fluyen de una persona o departamento hacia otros y puede ser cualquier cosa, desde comunicacin interna entre los diferentes componentes de la organizacin y lneas telefnicas hasta sistemas de cmputo que generan reportes peridicos para varios usuarios (8).

Las finalidades de los sistemas de informacin, como cualquier otro sistema dentro de una organizacin, son procesar entradas, mantener archivos de datos relacionados con la organizacin y producir informacin, reportes y otras salidas. Lo cual es una necesidad bsica en nuestro proyecto (9).

20

(8) (9)

Anlisis y Diseo de Sistemas de Informacin: James A. Senn Mac Graw Hill segunda edicin Anlisis y Diseo de Sistemas de Informacin: James A. Senn Mac Graw Hill segunda edicin

2.5. Base de Datos Una base de datos es un conjunto de datos que pertenecen al mismo contexto almacenados sistemticamente para su uso posterior. En informtica existen los Sistemas Gestores de Bases de Datos (SGBD), que permiten almacenar y posteriormente acceder a los datos de forma rpida y estructurada (10). Las aplicaciones ms usuales son para la gestin de empresas e instituciones pblicas. Tambin son ampliamente utilizadas en entornos cientficos con el objeto de almacenar la informacin experimental. 2.5.1. Modelos de Bases de Datos Un modelo de datos es bsicamente una "descripcin" de algo conocido como contenedor de datos (algo en donde se guarda la informacin), as como de los mtodos para almacenar y recuperar informacin de esos contenedores. Los modelos de datos no son cosas fsicas, son abstracciones que permiten la implementacin de un sistema eficiente de base de datos; por lo general se refieren a algoritmos, y conceptos matemticos.

21

(10)

Tomado de: Byteshift.de en <http://www.byteshift.de/web-design-Base_de_datos-es>

2.6. Mtodo ISAC. ISAC es un mtodo orientado al cliente en ambientes de sistemas de informacin. Comienza analizando los problemas en una organizacin, encuentra soluciones reales para problemas reales. Si una solucin involucra el desarrollo de un sistema de informacin, entonces ISAC contina desarrollando este sistema, lo pone en marcha, y estudia detalladamente la empresa. Sus caractersticas principales son: Mtodo orientado al cliente. Asegura que se comprendan las necesidades de informacin. El anlisis del problema y el estudio de actividades estn caracterizados por un alto grado de participacin de usuarios y desarrolladores. ISAC presenta cuatro estados las cuales son (11): 1. Anlisis de Cambio 2. Estudio de Actividades 3. Anlisis de Informacin 4. Implementacin. El anlisis de cambio es en general un mtodo de problemas. Sin embargo, si la solucin involucra la construccin de uno o mas sistemas de informacin, entones el estudio de actividades determina las propiedades de requerimiento del sistema de informacin. En suma, la decisin de automatizar o no un sistema de informacin es ejecutada, tales resultados especifican el comportamiento para cada sistema automatizado. De esta metodologa se utilizar la etapa del Anlisis de Cambio para la identificacin de problemas y la determinacin de los requerimientos que el usuario tiene con respecto a sus necesidades.

22

(11)

Anlisis de Sistemas: Ing. Silvana Paz, gestin 2003.

2.7. UML. UML es una especificacin de notacin orientada a objetos. Es un lenguaje grfico que sirve para modelar, disear, estructurar, visualizar, especificar, construir y documentar software
(12)

. UML proporciona un vocabulario comn para toda la

cadena de produccin, desde quien recaba los requisitos de los usuarios, hasta el ltimo programador responsable del mantenimiento. Es un lenguaje estndar para crear los planos de un sistema de forma completa y no ambigua. Fue creado por el Object Management Group, OMG, un consorcio internacional sin nimo de lucro que asienta estndares en el rea de computacin distribuida orientada a objetos, y actualmente revisa y actualiza peridicamente las especificaciones del lenguaje, para adaptarlo a las necesidades que surgen. (13). El prestigio de este consorcio es un aval ms para UML, considerando que cuenta con socios tan conocidos como la NASA, la Agencia Europea del Espacio ESA, el Instituto Europeo de Bioinformtica EBI, Boeing, Borland, Motorla y el W3C, por mencionar algunos. UML divide cada proyecto en un nmero de diagramas que representan las diferentes vistas del proyecto que ayudan a los ingenieros a visualizar, comunicar e implementar sus diseos. Los bloques bsicos de construccin de UML son tres: los elementos, las relaciones y los diagramas (14) (ver anexo 2). Los elementos son abstracciones que actan como unidades bsicas de construccin. Hay cuatro tipos: los estructurales, los de comportamiento, los de agrupacin y los de notacin. En cuanto a los elementos estructurales son

23

las partes estticas de los modelos y representan aspectos conceptuales o materiales.


(12) (14)

(13)

Los elementos de comportamiento son las partes dinmicas de Tomado de: solocursos.net en < http://www.solocursos.net/introduccion_uml-slccurso328408.htm>

Tomado de: seis.es en < www.seis.es/inforsalud04/ 2004_Inforsalud_TutorialUML-UP.doc >

los

modelos y representan comportamientos en el tiempo y en el espacio. Los elementos de agrupacin son las partes organizativas de UML, establecen las divisiones en que se puede fraccionar un modelo. Slo hay un elemento de agrupacin, el paquete, que se emplea para organizar otros elementos en grupos. Los elementos de notacin son las partes explicativas de UML, comentarios que pueden describir textualmente cualquier aspecto de un modelo. Slo hay un elemento de notacin principal, la nota. Las relaciones son abstracciones que actan como unin entre los distintos elementos. Hay cuatro tipos, la dependencia, la asociacin, la generalizacin y la realizacin. Los diagramas son la disposicin de un conjunto de elementos, que representan el sistema modelado desde diferentes perspectivas. UML tiene nueve diagramas fundamentales, agrupados en dos grandes grupos, uno para modelar la estructura esttica del sistema y otro para modelar el comportamiento dinmico. Los diagramas estticos son: el de clases, de objetos, de componentes y de despliegue. Los diagramas de comportamiento son: el de Casos de Uso, de secuencia, de colaboracin, de estados y de actividades.

24

2.8. Conceptos Bsicos del Modelado de Objetos Superficialmente, el trmino "orientado a objetos" significa software que organiza una coleccin de objetos discretos que contienen tanto estructuras de datos, como su comportamiento. Esto se opone a la programacin convencional, en la cual las estructuras de datos y comportamiento solamente estn relacionadas de forma dbil (15). La Programacin Orientada a Objetos desde el punto de vista computacional "es un mtodo de implementacin en el cul los programas son organizados como grupos cooperativos de objetos, cada uno de los cuales representa una instancia de alguna clase, y estas clases, todas son miembros de una jerarqua de clases unidas va relaciones de herencia" (16). 2.8.1. Objeto "Un objeto es cualquier cosa real o abstracta, acerca de la cual almacenamos datos y los mtodos que controlan dichos datos" (17). Un objeto define una representacin abstracta de las entidades del mundo, tangibles o no, con la intencin de emularlas Los objetos tienen dos caractersticas, que son su estado y su comportamiento. El estado es una situacin en la que se encuentra el objeto, tal que cumple con alguna condicin o condiciones particulares, realiza alguna actividad o espera que suceda un acontecimiento

25

(15) (16) (17)

Modelado y Diseo Orientado a Objetos: Rumbaugh, Blaha, Premerlani, Hed, Lorensen; Captulo 1 Tomado de: seis.es en < www.seis.es/inforsalud04/ 2004_Inforsalud_TutorialUML-UP.doc > Anlisis y Diseo Orientado a Objetos: James Martn, James Odell; Captulo 2.

2.9. Metodologa Orientada a Objetos RUP (Rational Unified Process - Proceso Unificado de Rational) Rational Unified Process (RUP) es un proceso de Ingeniera de Software planteado por Kruchten (1996) cuyo objetivo es producir software de alta calidad, es decir, que cumpla con los requerimientos de los usuarios dentro de una planificacin y presupuesto establecidos. Cubre el ciclo de vida de desarrollo de software, adems toma en cuenta las mejores prcticas en el modelo de desarrollo de software, en particular las siguientes: Desarrollo de software en forma iterativa. Manejo de requerimientos. Utiliza arquitectura basada en componentes. Modela el software visualmente (Modela con Unified Modeling Language,UML) Verifica la calidad del software. Controla los cambios. El proceso iterativo de RUP se organiza en fases, (18) cada fase se concluye con un hito o piedra de milla (mile stone) principal (ver figura 1). Es importante resaltar que la inclusin de hitos o puntos de revisin, es sumamente importante y en estos puntos se revisan los requerimientos establecidos para cada fase, basados en los controles de calidad. De esta manera, si un producto o proceso no pasa el punto de revisin de calidad, se redisea o se cancela, evitando as, los problemas de coste extra, de retrabajo, y de productos de mala calidad, que no satisfacen los

26

requerimientos establecidos a nivel tcnico y de diseo grfico. Los puntos de revisin estn basados a su vez en cuestionarios elaborados a partir de mtricas establecidas producto de la experiencia y de la investigacin (19).

(18) (19)

Tomado de: seis.es en < www.seis.es/inforsalud04/ 2004_Inforsalud_TutorialUML-UP.doc > Modelado Orientado a Objetos: Rumbaugh, Blaha, Premerlani, Hed, Lorensen; Captulo 1 En y laDiseo figura 2 se puede observar la expresin grfica equivalente al tiempo

esfuerzo que se dedican a cada una de las fases de RUP. En esta grfica se puede observar que la inversin de tiempo y esfuerzo en la primera y segunda fase es pequea en comparacin con la tercer fase, garantizando as que la mayor parte del trabajo, costo y esfuerzo se realice si y solo si, ha pasado el segundo hito, o sea, el segundo control de revisin de calidad.

Figura 2. Fases de Rational Unified Process (RUP) (Kruchten, 1996)

1 fase

2 fase

3 fase

4 fase

Figura 2.Expresin grfica del tiempo y esfuerzo dedicados a cada fase de RUP

2.9.1. Ciclo de Vida. (20) El ciclo de vida de un proyecto de software se descompone en el tiempo en cuatro fases secuenciales: INICIO, ELABORACIN, CONSTRUCCIN y TRANSICIN, que, como mencionamos anteriormente, concluyen en un hito

27

principal cada una. Al final de cada fase el equipo de direccin del proyecto realiza una evaluacin para determinar si los objetivos de la fase se cumplieron, y continuar as a la siguiente fase. 2.9.1.1 Inicio
(20)

Tomado de: binarea.net en < www.binarea.net/descargas/binarea_introduccion_proceso_unificado.pdf>

Su meta principal es lograr el consenso de todos los involucrados acerca de los objetivos del ciclo de vida del proyecto. Es muy importante especialmente en proyectos nuevos en que existen riesgos significativos en el negocio o la implementacin de los requisitos, y deben ser solucionados para que el proyecto proceda. Para los proyectos que se enfocan en mejorar sistemas existentes, esta fase es ms breve, pero an as centrada en asegurar que el proyecto vale la pena y se puede realizar. Hito: Establecer el mbito del producto, la identificacin de los principales riesgos y la viabilidad del proyecto. 2.9.1.2 Elaboracin El propsito de la etapa de Elaboracin es crear la lnea base de la arquitectura para as disponer de unos cimientos slidos sobre los que se basar el grueso del esfuerzo de diseo e implementacin durante la fase de Construccin. La arquitectura evoluciona de los requisitos ms significativos considerados (aquellos que tienen un fuerte impacto en la arquitectura del sistema) y la evaluacin de riesgos. La estabilidad de la arquitectura se evala mediante el uso de prototipos de arquitectura. Hito: Obtener una lnea base de la arquitectura del sistema, capturar la mayora de los requisitos y reducir los riesgos principales as como permitir la escalabilidad del equipo del proyecto durante la fase de construccin.

28

2.9.1.3. Construccin En la fase de Construccin se deben aclarar los requisitos restantes y completar el desarrollo del sistema basndose en la arquitectura que ha sido aadida a la lnea base. Puede ser vista como un proceso de fabricacin donde se hace nfasis en la administracin de los recursos y el control de operaciones para optimizar costes, planificaciones y calidad. En este sentido la administracin experimenta una transicin del desarrollo de propiedad intelectual durante las fases de Inicio y Elaboracin al desarrollo de productos instalables durante la Construccin y Transicin. Hito: Desarrollo del sistema con calidad de produccin y prepararse para la entrega al equipo de transicin. Toda la funcionalidad debe haber sido implementada y las pruebas para el estado beta de la aplicacin completadas. Si el proyecto no logra alcanzar este hito, entonces la transicin deber posponerse una iteracin. 2.9.1.4 Transicin La atencin se enfoca en asegurar que el software est disponible para los usuarios finales. Incluye las pruebas del producto como parte de su preparacin para ser entregado, y la realizacin de ajustes menores en respuesta a la retroalimentacin recibida de los usuarios. En este punto del ciclo de vida la retroalimentacin de los usuarios debe enfocarse fundamentalmente en ajustes especficos y de corto alcance al producto junto a otros temas como configuracin, instalacin, y usabilidad. Referencias a otros ajustes estructurales mayores debieron haber sido solucionados anteriormente en el ciclo de vida y debern documentarse para futuras generaciones

29

del software. Hito: Consiste en decidir si los objetivos se cumplieron y si debe comenzarse otro ciclo de desarrollo. Es el resultado de la revisin y aceptacin por parte del cliente de los artefactos que le han sido entregados. 2.9.2. Artefactos (21) Dentro del proceso unificado de desarrollo de software se denomina artefacto a todo producto o subproducto del proceso de fabricacin. Dentro de esto se encuentra desde el propio cdigo fuente hasta la documentacin aportada por el cliente y la entregada al completarse cada hito dentro del proyecto. En este apartado mencionaremos solamente algunos de los ms representativos para el cliente, por lo general aquellos que se convierten en documentos que se incorporan a la informacin que se guarda del proyecto. 2.9.2.1. Especificaciones de los casos de uso Es una coleccin de documentos que recogen la especificacin completa de cada caso de uso. Cada uno debe contener los campos: nombre, descripcin, actores, precondiciones, post-condiciones, flujo bsico, flujos alternativos, puntos de extensin, entre otros que describen en detalle un caso de uso. 2.9.2.2. Modelo de casos de uso Es un modelo de las funciones concebidas del sistema y su entorno. Es una entrada importante a actividades de anlisis, diseo y prueba. Incluye todos los actores y casos de uso del sistema con sus descripciones. Puede ser entregado directamente en el formato que utilice la herramienta de modelacin o gestin empleada, o mediante un informe de este modelo que contenga toda esta informacin que se complementar con las Especificaciones de los casos de uso.

30

(21)

Tomado de: binarea.net en < www.binarea.net/descargas/binarea_introduccion_proceso_unificado.pdf>

2.9.2.3. Especificaciones suplementarias [opcional] Este artefacto captura los requerimientos del sistema que no fueron recogidos en el Modelo de casos de uso. Generalmente contiene los requerimientos no funcionales del sistema. 2.9.2.4. Especificacin de requisitos del software [opcional] En los casos en que la empresa cliente no desee utilizar el enfoque de casos de uso a la gestin de requisitos, podr entregar en lugar de los 3 artefactos descritos anteriormente un solo documento que recoja las caractersticas, requisitos funcionales y no funcionales del sistema, as como otra informacin til como por ejemplo: restricciones en el diseo e implementacin, componentes comprados a terceros, interfases de hardware o software, etc. 2.9.2.5. Documento de arquitectura del software Este documento brinda un resumen de la arquitectura utilizando varias vistas diferentes que muestran distintos aspectos del sistema. Es un medio de comunicacin entre el arquitecto de software y otros miembros del equipo del proyecto, acerca de las decisiones significativas que han sido tomadas para la arquitectura. 2.9.2.6. Modelo de diseo Es una abstraccin de la implementacin del sistema que normalmente se utiliza para concebir y documentar su diseo. Es un artefacto compuesto que contiene

31

todas las clases, subsistemas, paquetes, colaboraciones y las relaciones entre ellas. Tambin contiene las realizaciones de los casos de uso.

2.9.2.7. Modelo de datos [opcional] Describe la representacin fsica y lgica de los datos persistentes utilizados por la aplicacin. Se utilizar siempre que se necesiten manejar datos persistentes. Usualmente describir los diferentes elementos componentes de la estructura de una base de datos relacional. 2.10. Red de Computadores. Sistema de elementos interrelacionados que se conectan mediante un vnculo dedicado o conmutado para proporcionar una comunicacin local o remota (de voz, vdeo, datos, etc.) y facilitar el intercambio de informacin entre usuarios con intereses comunes. 2.10.1. Lan (local area network). Son las redes de rea local. La extensin de este tipo de redes suele estar restringida a una sala o edificio, aunque tambin podra utilizarse para conectar dos o ms edificios prximos. 2.10.2. Topologa de Red. Es el trmino tcnico que describe disposicin fsica en la que est configurada una red; est determinada en parte, por la manera en que las PCs administran el acceso a la red y en parte a las limitaciones del sistema de seales.

32

2.10.2.1. Topologa en Estrella. Esta topologa consiste en un nodo central del cul salen los cableados para cada estacin; las estaciones se comunican unas con otras a travs del nodo central; hay dos formas de funcionamiento de este nodo: este nodo es un mero repetidor de las tramas que le llegan (cuando le llega una trama de cualquier estacin, la retransmite a todas las dems), en cuyo caso, la red funciona igual que un bus; otra forma es de repetidor de las tramas pero slo las repite al destino (usando la identificacin de cada estacin y los datos de destino que contiene la trama) tras haberlas almacenado. Una ventaja de esta configuracin es que cada conexin no tiene que soportar mltiples PCs en competencia por acceso, de manera que es posible lograr altas frecuencias de transferencia de datos (aunque la mquina central deba ser bastante rpida). 2.10.3. Concentrador. Centro de cableado en topologa tipo estrella que puede amplificar una seal y transmitirla (concentrador activo) o simplemente dejarla pasar(concentrador pasivo). 2.10.3.1. Concentrador Ethernet. Centro de cableado que se usa para Ethernet 100base-T en un sistema de cableado atrs centro (Home Run). Es un dispositivo que acta como punto de concentracin para la topologa de bus que se requiere para Ethernet.

33

2.10.4. Par Trenzado Sin Apantallar (Utp). Es el soporte fsico ms utilizado en las redes de rea local, pues es barato y su instalacin es barata y sencilla. Por l se pueden efectuar transmisiones digitales (datos) o analgicas (voz). Consiste en un mazo de conductores de cobre (protegido cada conductor por un dielctrico), que estn trenzados de dos en dos para evitar al mximo la diafona. Un cable de pares trenzados puede tener pocos o muchos pares; en aplicaciones de datos lo normal es que tengan 4 pares. Uno de sus inconvenientes es la alta sensibilidad que presenta ante interferencias electromagnticas. En Noviembre de 1991, la EIA/TIA 568 define las siguientes categoras de cable: Categora 3 hasta 16MHz. Categora 4 hasta 20 MHz. Categora 5 hasta 100MHz. Los cables de categora 1 y 2 se utilizan para voz y transmisin de datos de baja capacidad (hasta 4Mbps). Este tipo de cable es el idneo para las comunicaciones telefnicas, pero las velocidades requeridas hoy en da por las redes necesitan mejor calidad. Los cables de categora 3 han sido diseados para velocidades de transmisin de hasta 16 Mbps. Se suelen usar en redes IEEE 802.3 10BASE-T y 802.5 a 4 Mbps. Los cables de categora 4 pueden proporcionar velocidades de hasta 20 Mbps. Seusan en redes IEEE 802.5 Token Ring y Ethernet 10BASE-T para largas distancias. Los cables de categora 5 son los UTP con ms prestaciones de los que se dispone

34

hoy en da. Soporta transmisiones de datos hasta 100 Mbps. Cada cable en niveles sucesivos maximiza el traspaso de datos y minimiza las cuatro limitaciones de las comunicaciones de datos: atenuacin, crosstalk, capacidad y desajustes de impedancia. El cable UTP categora 5 posee 4 pares bien trenzados entre s:

Par 1: Blanco/Azul * Azul ----------------Contactos: 5 * 4 Par 2: Blanco/Naranja * Naranja-------Contactos: 3 * 6 Par 3: Blanco/Verde * Verde------------Contactos: 1 * 2 Par 4: Blanco/Marrn * Marrn--------Contactos: 7 * 8 Esta normalizado por los apndices EIA/TIA TSB 36 (cables) y TSB 40 (conectores) Es la ms alta especificacin en cuanto a niveles de ancho de banda y performance. Es una especificacin genrica para cualquier par o cualquier combinacin de pares. No se refiere a la posibilidad de transmitir 100 Mb/s para solo una sola combinacin de pares elegida. El elemento que pasa la prueba lo debe hacer sobre "todos" los pares.

Los elementos certificados bajo esta categora permiten mantener las especificaciones de los parmetros elctricos dentro de los lmites fijados por la norma hasta una frecuencia de 100 Mhz en todos sus pares.

Los parmetros elctricos que se miden son: 1. Atenuacin en funcin de la frecuencia (db) 2. Impedancia caracterstica del cable (Ohms) 3. Acoplamiento del punto ms cercano (NEXT- db) 4. Relacin entre Atenuacin y Crostalk (ACR- db)

35

5. Capacitancia (pf/m) 6. Resistencia en DC (Ohms/m) 7. Velocidad de propagacin nominal (% en relacin C) 8. Distancias permitidas: 9. El total de distancia especificado por norma es de 99 metros. 10. El lmite para el cableado fijo es 90 m y no est permitido excederse de esta distancia, especulando con menores distancias de patch cords. 11. El lmite para los patch cord en la patchera es 6 m. El lmite para los patch cord en la conexin del terminal es de 3 m. 2.10.5. La Norma 100baseT (IEEE 802.3U). Durante los aos 80, la tecnologa dominante en las LAN eran las redes de tipo Ethernet, cumpliendo estas las exigencias de ancho de banda en la mayora de los casos, actualmente la informtica, se encuentra en un momento en el que cada pocos meses se producen grandes avances, los sistemas operativos, siempre basados en complejas interfaces grficas, exigen mas recursos hardware, as mismo las aplicaciones son cada vez mas complejas y capaces de manejar archivos de gran tamao, es en este punto cuando se encuentra que las redes Ethernet de10 Mbps son un cuello de botella, surge ante tal necesidad una nueva especificacin de Ethernet, que permite un mayor ancho de banda (100 Mbps). Se crea entonces Fast Ethernet como respuesta a la demanda de mayores anchos de banda, capacitando as las conexiones de las nuevas aplicaciones, como bases de datos, o aplicaciones cliente-servidor, adems con la gran ventaja que supone el pequeo gasto de actualizacin a Fast Ethernet, si lo comparamos con soluciones como FDDI o ATM, manteniendo tambin una total compatibilidad e interoperabilidad con Ethernet. Las caractersticas de 100Base T son:

36

Una ratio de transferencia de100 Mbps. Una subcapa (MAC) idntica a la de 10BaseT. Formato de tramas idntico al de 10BaseT. El mismo soporte de cableados que 10BaseT (cumpliendo con EIA/TIA-568). Mayor consistencia ante los errores que los de 10 Mbps. La norma 100BaseT (IEEE 802.3u) se comprende de cinco especificaciones.

stas definen la subcapa (MAC), la interfaz de comunicacin independiente (MII), y las tres capas fsicas (100BaseTX, 100BaseT4 y 100BaseFX). 2.10.6. Conectores RJ. El conector RJ se ha diseado en varios estndares distintos, cada uno con una nomenclatura. Los ms usuales son el RJ-11 y RJ-45. RJ-11.- Puede albergar como mximo un total de 6 pines, aunque podemos encontrarlo en el mercado con los formatos de 2, 4 6 pines segn la aplicacin a la cual estn destinados. RJ-45.- Puede albergar como mximo un total de 8 pines aunque al igual que el anterior lo podemos encontrar en diferentes formatos segn nuestras necesidades. El ms usual es el de 8 pines, el cual se usa en el estndar RDSI. Para manejar estos conectores se usarn herramientas diseadas para tal efecto, recomendndose una de tipo universal para RJ, que es vlida para todo tipo de conectores RJ en el mercado. 2.10.7. Full-Duplex. La comunicacin Full-Duplex para 100BaseTX y 100BaseFX es llevada a cabo desactivando la deteccin de las colisiones y las funciones de loopback, esto es necesario para asegurar una comunicacin fiable en la red. Slo los switches pueden ofrecer Full-Duplex cuando estn directamente conectados a estaciones o a servidores. Los hubs compartidos en 100BaseT deben operar a Half-Duplex para

37

detectar colisiones entre las estaciones de los extremos. El control del flujo puede implementarse en base a un enlace-enlace o en base a un extremo que permite a todos los dispositivos reducir la cantidad de datos que reciben. Como el control del flujo tiene implicaciones ms all de Full-Duplex y de la subcapa MAC, los mtodos y normas todava estn bajo consideracin por el comit IEEE 802.3x. Fast Ethernet: Ventajas

Los datos pueden moverse entre Ethernet y Fast Ethernet sin traduccin protocolar.
o

Fast Ethernet tambin usa las mismas aplicaciones y los mismos drivers usados por Ethernet tradicional. Fast Ethernet est basado en un esquema de cableado en estrella. Esta topologa es ms fiable y en ella es ms fcil de detectar los problemas que en 10Base2 con topologa de bus. En muchos casos, las instalaciones pueden actualizarse a 100BaseT sin reemplazar el cableado ya existente. Fast Ethernet necesita slo 2 pares de UTP categora 5, mientras 100VG-AnyLAN necesita 4 pares. As en algunos casos a Fast Ethernet se la prefiere.

2.10.8. Cableado Estructurado Es un sistema de cableado capaz de integrar tanto a los servicios de voz, datos y vdeo, como los sistemas de control y automatizacin de un edificio bajo una plataforma estandarizada y abierta. El cableado estructurado tiende a estandarizar los sistemas de transmisin de informacin al integrar diferentes medios para soportar toda clase de trfico, controlar los procesos y sistemas de administracin de un edificio.

38

2.10.9. Switches. Son muy similares a los hubs, solo que no se comparte el ancho de banda. Un switch mediante memoria no voltil, permite que cada uno de sus puertos posea su propio ancho de banda. Adems de esto, son equipos que transmiten la informacin solo al puerto o puertos que requieran de la misma. Un switch puede soportar mltiples conversaciones y permite movilizar mayor trfico que un hub. Usualmente, por no decir "siempre", los switches trabajan al nivel de la capa 2 del modelo OSI, algunas excepciones manejan paquetes al nivel de la capa 3.

2.10.10. Protocolos De Comunicaciones. Definen las normas que posibilitan que se establezca una comunicacin entre varios equipos o dispositivos, ya que estos equipos pueden ser diferentes entre s. El Protocolo TCP/IP.- Es el protocolo comn utilizado por todos los ordenadores conectados a Internet, de manera que stos puedan comunicarse entre s. Hay que tener en cuenta que en Internet se encuentran conectados ordenadores de clases muy diferentes y con hardware y software incompatibles en muchos casos, adems de todos los medios y formas posibles de conexin. Aqu se encuentra una de las grandes ventajas del TCP/IP, pues este protocolo se encargar de que la comunicacin entre todos sea posible. TCP/IP es compatible con cualquier sistema operativo y con cualquier tipo de hardware.

39

TCP/IP no es un nico protocolo, sino que es en realidad lo que se conoce con este nombre es un conjunto de protocolos que cubren los distintos niveles del modelo OSI. Los dos protocolos ms importantes son el TCP (Transmisin Control Protocol) y el IP (Internet Protocol), que son los que dan nombre al conjunto. 2.10.11. Infraestructura Necesaria Para Instalacin. 2.10.11.1. Canalizaciones de edificios. Para La instalacin de un sistema de cableado estructurado se puede usar toda la canalizacin de comunicaciones del edificio, siempre que permita su instalacin el dimetro de los conductores. Por esto, es preferible realizar el proyecto del edifico teniendo en cuenta las instalaciones que necesitar en cuanto voz, datos, seguridad de robo e incendios, etc. Las canalizaciones pueden ser del tipo ackermann (bandeja metlica y registros incrustados bajo el cemento del suelo, tubo corrugado, tubo de PVC, falso techo, falso suelo, etc). 2.10.11.1.1. Falso Suelo. La instalacin en este medio es una de las ms fciles ya que slo tendremos que levantar las baldosas para realizar el tendido del cable y para sacarlo a la superficie, ser suficiente con un taladro y si el mecanismo va empotrado hay que mecanizar la baldosa. La ventaja es que no tenemos que usar canalizaciones ni escaleras. 2.10.11.1.2. Canalizaciones. Tambin se puede usar la canalizacin existente en el edificio para lo cual

40

tiene que tener suficiente seccin para albergar las mangueras y repartidores de planta. Esas podrn ir a la altura del suelo, por el rodapi, o por las paredes.

2.10.11.1.3. Falso Techo. Para instalaciones de este tipo no es necesario instalar prcticamente ningn elemento adicional, salvo en algunos casos que no tengamos las suficientes verticales dentro de la sala para acceder a algunos lugares, pudindose instalar columnas metlicas para descender hasta el puesto de trabajo. Este tipo de columna es aluminio prefabricado y viene con unas guas para su sujecin de mecanismos pero tendremos que mecanizarla (hacer los taladros o ranuras necesarias) para poder instalar los mecanismos. 2.11. Carta Gantt. Tambin conocida como Cronograma, es una tcnica de visualizacin de actividades que muestra una secuencia de ellas y para cada una, el tiempo que se requiere para cumplirlas (Cuadro 1).

Cuadro 1. Carta Gantt

Se espera que en una Carta Gantt estn anotadas todas las actividades del proyecto desde el principio al fin y se indique la duracin de cada una. En caso de que una actividad sea requisito para otra, slo podr comenzar cuando la anterior est terminada. Lo mismo si dos actividades son ejecutadas por la misma persona, se debe indicar que la segunda comenzar cuando la primera ya est terminada. Las ventajas

41

principales de una Carta Gantt son que permite revisar de manera simple lo proyectado versus lo realizado; que es de fcil representacin y rpido aprendizaje y que es fcil de leer. Las desventajas radican en que para los proyectos complejos no muestra la interdependencia entre actividades y no indica qu actividades pueden atrasarse sin influir en el trmino programado del proyecto.

Potrebbero piacerti anche