ࡱ> q` (bjbjqPqP 4::oW*******>llllm>nqqqqrTs!soqqqqqq$h:9*GrrGG**qqG*q*qoGo **+qn l]RNo0N++*1sBsyx}1s1s1s 1s1s1sGGGG>>>IP>>>P>>>****** Administracin de recursos informticos La administracin de los recursos informticos tiene que ver con la forma en que planeamos, organizamos, dirigimos y controlamos nuestros bienes informticos de tal suerte que todos los costos involucrados (adquisicin, mantenimiento, capacitacin, uso, infraestructura, etc.) sean optimizados. Cuando la inversin en tecnologa se hace necesaria, la optimizacin de los costos involucrados y el control que se debe ejercer sobre los recursos informticos debe convertirse en una prioridad, a la suma de todos los costos involucrados en la adquisicin, uso y mantenimiento de la tecnologa informtica se le conoce como el Costo Total de Propiedad. La administracin de recursos informticos conlleva una seria responsabilidad, pues la inversin no termina con la adquisicin del recurso, debido a que la infraestructura tecnolgica, la preparacin del recurso humano que utiliza la tecnologa y el mantenimiento de la misma son un ciclo constante que se repite hasta terminar con la vida til del recurso. El ciclo de vida til de un recurso informtico, por ejemplo un equipo de cmputo, es de aproximadamente cuatro aos, aunque con el avance tan rpido de la tecnologa este tiempo se est reduciendo. Por qu es importante administrar los recursos informticos? Bueno, cuando la vida til del recurso informtico termina, el Gobierno del Estado debe ser capaz de definir estrategias para el cambio y uso de nueva tecnologa. Estas estrategias deben permitir de alguna manera, optimizar el Costo Total de Propiedad y adems deben incidir de manera importante en las tomas de decisiones para la inversin en tecnologa y el subsecuente retorno de la inversin. Las actividades que conlleva la administracin de recursos informticos se relacionan con: El control del inventario de hardware y software (control de las aplicaciones, licencias y sus versiones), La medicin de los programas de cmputo con el fin de monitorear su uso efectivo, La administracin del uso del espacio en disco y el ancho de banda en la red, Los estndares de uso y la definicin de polticas para buen uso del recurso informtico, La implementacin de procesos de auditorias de software en forma peridica, Procesos de respaldos y recuperacin de informacin, La obtencin de informacin para determinar los requerimientos de adquisicin de hardware y software, Los presupuestos respectivos, La organizacin de la mesa de ayuda (Help-Desk) para la atencin de usuarios, El control de los niveles de servicio en la atencin de problemas y cambios, La organizacin del mantenimiento preventivo que mantenga el buen funcionamiento del recurso de cmputo, La implantacin de software antivirus para prevenir dao a la informacin, Los controles en las garantas y seguros de los bienes informticos, La optimizacin en la generacin de los presupuestos para la adquisicin y/o cambio de tecnologa. Como se puede observar, la administracin de estos recursos es una labor que sin el soporte adecuado a travs de procedimientos, mtodos y tecnologa, puede convertirse en una labor ardua y complicada. Hoy en da todas las Dependencias del Gobierno del Estado deben estar preparadas para administrar de mejor forma sus recursos informticos. Con el crecimiento de las redes computacionales y la diversidad de plataformas, software y dispositivos, la bsqueda de herramientas y formas de administrar estas tecnologas de informacin se convierte en una necesidad ms apremiante. Inclusive una funcin que se encargue de administrar las tecnologas de informacin debera ser parte fundamental en todo el Gobierno del Estado ya que se cuenta con un buen nmero de activos informticos. Deben considerarse tres aspectos de vital importancia, que si son instrumentados de buena forma, pueden producir beneficios sustanciales en el tiempo y costos involucrados en la administracin de los recursos de tecnologas de informacin: El primer punto a considerar son los relacionados con la Mejora Tecnolgica e involucra aspectos de: Administracin de Activos, Sistemas, PC's, Escalabilidad, Proteccin y Mesa de Ayuda (Help-Desk). Cada uno de ellos puede ser implementado desde un nivel bsico hasta el ms avanzado e involucra la consideracin de esquemas automatizados bsicos hasta sistemas de control sofisticados. El segundo punto se relaciona con la Mejora de procesos e incluye aspectos como estandarizacin y administracin de usuarios. Al igual que en el punto anterior pueden implementarse de forma bsica o avanzada. El tercer punto involucra aspectos relacionados con la Mejora del Personal dentro del cual se incluyen aspectos relacionados con la capacitacin del usuario, capacitacin del personal de sistemas, motivacin del personal de soporte a usuarios. Si cada uno de los puntos sealados se toma en cuenta para la administracin de los recursos informticos podemos asegurar que los costos involucrados en la administracin de los mismos se optimizarn y la planeacin estratgica para el cambio de tecnologa ser realizada con bases ms slidas. El control del inventario de hardware y software es la base donde se sustenta la administracin de los activos. De un buen control en el inventario derivamos las estrategias adecuadas para optimizar los costos en la escalacin de nuestro equipo informtico. El Qu?, Cmo? , Cundo? y Cunto? invertir en nueva tecnologa se responden a travs de una buena administracin del inventario. Qu pasos debemos seguir para llevar un control adecuado del inventario? Existen desde formas bsicas de control que pueden ser llevadas a cabo de forma muy simple y de forma manual hasta formas ms avanzadas que requieren el apoyo de herramientas de software que faciliten el trabajo, todo depende del tamao de la Dependencia. No es lo mismo controlar el inventario de una Dependencia que tiene 20 computadoras en una misma ubicacin que en una que tiene 50 o 100, y ms an en aquellas Dependencias que tienen un gran nmero de equipo disperso en diferentes oficinas. En Dependencias con menos de 20 equipos, un control manual puede resultar eficiente si se lleva a cabo a travs de revisiones peridicas y la informacin es actualizada de manera constante. La informacin a controlar se centra especficamente en las caractersticas del equipo que ha sido asignado a cada usuario. Las caractersticas del equipo pueden ser: Externas - Marca, Modelo, Numero de serie del equipo, Proveedor del equipo, Fecha de adquisicin, garanta, etc. Internas - Tipo de procesador, su velocidad, la capacidad de memoria RAM, la capacidad del disco duro y otras que puedan ser importantes considerar, segn hardware que se est inventariando (PC's, Servidores, etc.). Adems de las caractersticas de hardware se debe llevar un registro del software que est instalado en cada PC. Para ello es importante contar con informacin a detalle del software instalado en cada PC - Nombre del Software, versin, idioma, fabricante - as como tambin el registro del proveedor con el que adquirieron el producto y bajo que esquema de licenciamiento se adquiri. Estas caractersticas son convenientes asociarlas al usuario que utiliza el equipo, de tal forma que podamos llevar un registro completo de los datos del usuario (Nombre, rea y/o departamento al que pertenece y otros que consideremos importantes) para despus poder analizar toda esta informacin para tomar decisiones. Se preguntarn de qu les sirve llevar un registro de toda la informacin anterior. He aqu algunos casos en los que esta informacin resulta de utilidad: Robo Hormiga: Un da, en un equipo deja de funcionar el procesador de palabras que tena instalado. Usted acude a revisar el equipo y se encuentra que el equipo originalmente debera tener 64Mb de Memoria y ahora tiene 32Mb. Dnde quedaron los otros 32Mb? Escalacin: Se necesita instalar un nuevo software que requiere 64Mb en RAM y contar con procesador Pentium III a 500Mhz. Qu equipos tienen esa capacidad para poder instalar el software? Migracin: Se desea saber si es conveniente cambiar a la nueva versin del sistema operativo, para ello se requiere saber cual sera la mejor forma de adquisicin de las licencias correspondientes. Usted realiza un anlisis de las capacidades de sus equipos para soportar el cambio de versin y de los esquemas de licenciamiento que sean ms competitivos pues tiene la informacin necesaria para hacerlo. Mantenimiento: Usted desea incluir en una pliza de mantenimiento a los equipos de su organizacin, para ello revisa cules estn en garanta todava, de tal suerte que no es necesario incluirlos. Auditoria: La BSA les enva una carta de desistimiento invitndolos a regularizar su software para no tener copias piratas. Al revisar frecuentemente sus equipos conoce el software que tiene instalado y lleva el control de las licencias correspondientes por lo que la carta anterior no les debera preocupar en lo mas mnimo. Capacitacin: Se desea conocer por Dependencia que software de oficina se tiene instalado, de tal forma que pueda programar la capacitacin de los usuarios optimizando los costos. Salida de un empleado: Cuando un empleado deja de colaborar en su Dependencia debe verificar que l mismo entregue el equipo asignado tal cual se lo dieron a su ingreso a la Dependencia. El control del inventario de hardware y software puede realizarse en forma bsica, media o avanzada y puede requerir del uso de herramientas automatizadas dependiendo del nivel de control que se desea obtener. Un inventario de hardware consiste de un listado de todo el hardware en la Dependencia. El inventario de hardware debe incluir un listado completo de todos los componentes de la red incluyendo PC's, Servidores, perifricos y dispositivos de red y de comunicaciones. La informacin del inventario incluye identificacin relevante (nmeros de serie, nmeros de inventario, cdigos de barra, etc.) de cada componente - PC's, Servidores, perifricos y hardware de la red. Adems de lo anterior es conveniente mantener un historial de los aspectos financieros (registros de adquisicin, arrendamiento, seguros, depreciacin) fsicos (movimientos, adiciones, cambios) y tcnicos. Se dice que un inventario de software es bsico cuando ste se lleva en forma manual y no se encuentra integrado en un archivo. Generalmente este inventario es mantenido y actualizado en forma manual y contiene informacin mnima acerca del software. Su objetivo se centra en mantener los requerimientos mnimos para evitar rezagos en la actualizacin de software y provee un mecanismo de prueba del software instalado en cada equipo. Esta estrategia de control permite mnimos costos pero el retorno de inversin tambin es mnimo. Cuando se emplean herramientas automatizadas para llevar el control del inventario y stas se apoyan en un proceso de administracin de cambios se habla de un control intermedio. La informacin que generan las herramientas automatizadas permite la resolucin de problemas en forma reactiva y la planeacin tctica de presupuestos y planeacin de actualizaciones de software se hace ms efectiva. El objetivo de este control es la disminucin de los costos y mejorar la eficiencia en los niveles de servicio del rea de atencin a usuarios. Existen herramientas automatizadas ms avanzadas que permiten un control del software a travs del monitoreo de su uso, stas herramientas pueden contener ya polticas definidas del software que est autorizado y a travs de esas polticas restringen su uso. Obviamente estas herramientas se integran al inventario de SW pero no son parte de l sino que utilizan la informacin ya depositada en el inventario para realizar su control. Se recomienda que la informacin se concentre en un archivo central, tambin es muy recomendable que esta informacin se mantenga y actualice en forma peridica y que incluya los trminos de las licencias de uso, fecha de adquisicin, nombre del usuario que usa el software, detalles de instalacin, acuerdos de mantenimiento, monitoreo de uso y otros datos que sean de importancia para su administracin. Como habrn de observar el inventario de software es de suma importancia pues permite administrar de mejor forma las licencias, negociar contratos de soporte, planear actualizaciones de software, resolver problemas relacionados con su uso y por supuesto permite una administracin financiera adecuada. Cuando el control del inventario de hardware y software ya se ha implementado en la Dependencia y se mantiene actualizado en forma peridica, debe implantarse otra prctica de buen uso, nos referimos a la "Administracin de Software." La Administracin de Software es la funcin que permite asegurar a las Dependencias el cumplimiento de las licencias del software que se tiene instalado as como el buen uso que se haga del mismo. Los elementos que intervienen en una buena administracin de software son: El control de las aplicaciones y versiones de software: Generalmente utilizado para procesos de migracin y actualizacin. Consiste en llevar un control de las aplicaciones que estn instaladas en la Dependencia de tal modo que cuando exista la necesidad de cambiar a una nueva versin o aplicar algunos "parches" al software que presenta problemas se pueda realizar de manera uniforme. Por ejemplo, el pasado problema del ao 2000. Existan aplicaciones que se haban desarrollado con MS-Access 2.0, el cual presentaba problemas en el clculo de fechas. La recomendacin era que todas las aplicaciones creadas con esa versin fueran actualizadas con la nueva versin de MS-Access. El llevar un control de las aplicaciones que fueron desarrolladas con esa versin permiti a muchas organizaciones evitar un problema mayor. El beneficio que se obtiene con un buen control de versiones lo observamos en los procesos de actualizacin de licencias pues se puede planear de mejor forma las inversiones en adquisicin de licencias de software y con ello optimizar los costos. Auditoria de Software: La auditoria de software permite evaluar el grado de exposicin en el que se encuentra una Dependencia con respecto al software que tiene instalado en sus equipos y las correspondientes licencias de uso. Los beneficios que se obtienen son la eliminacin del riesgo de enfrentar demandas civiles y penales por tener software sin la correspondiente licencia. As tambin permite conocer cmo se llevan a cabo los controles definidos para la administracin del software. Medicin de los programas de cmputo: "Lo que no se puede medir...No se puede controlar". La importancia de conocer el uso que se le est dando al software permite saber si hay retorno de la inversin realizada. El comprar licencias de software sin analizar el uso que se les va a dar puede ser causa de que los costos de adquisicin se eleven. Por ejemplo, si tenemos instalado en un servidor un producto de oficina (Procesador de palabras, hoja de clculo, presentaciones etc.) como MS-Office, Corel-Perfect Office o Lotus Smartsuite que es utilizado en promedio por 30 usuarios de los 50 que lo utilizan de forma espordica, es posible instalar en el servidor un software encargado de monitorear el uso del producto, para poder ajustar la compra de las licencias o actualizaciones al uso real que se le est dando. En vez de adquirir 50 licencias podra adquirir solamente 30. El beneficio obtenido es la reduccin en la inversin. La administracin del espacio en disco en la red: Consiste en monitorear constantemente la informacin residente en los discos duros del servidor o de las PC's de las Dependencias. Existe mucha informacin que no es parte del proceso sustantivo en una Dependencia que ocupa espacio en disco y que todo usuario debe depurar como parte de su responsabilidad. Nos referimos a notas de e-mail, archivos de caractersticas singulares - fotos, imgenes, tarjetas electrnicas de felicitacin, los famosos tapices y protectores de pantalla - adems de toda aquella informacin que NO es informacin de trabajo. El beneficio de administrar efectivamente el espacio en disco evita que estemos actualizando continuamente las PC's con discos duros de mayor capacidad y la realizacin de inversiones innecesarias. El conocido comentario por parte del usuario "Necesito mayor capacidad en disco" de ahora en adelante debe ser justificado antes de instalarle un nuevo disco. La definicin de estndares, polticas y procedimientos: Si todo lo descrito anteriormente no se encuentra sustentado a travs estndares, polticas y procedimientos de control, de nada servirn los esfuerzos realizados. Dentro de los estndares se pueden definir aquellos relativos al uso de software de base (sistemas operativos), software de oficina (paquetes administrativos, hojas de clculo, procesadores de texto, etc.) , software de red. De las polticas se pueden definir polticas de uso de software entre otras y de los procedimientos se pueden incluir aquellos relativos al proceso de adquisicin de licencias, instalacin de software y actualizacin. Todo lo anterior debe ser soportado por un buen plan de concientizacin que comunique de manera efectiva y responsabilice a todos los usuarios del Gobierno del Estado del buen uso del software. Administracin de los Recursos Informticos Todos los recursos informticos sern administrados por la Gerencia General Administrativa a travs de la Unidad de Informtica, la cual intervendr en los procedimientos de adquisicin, recepcin, registro, distribucin y conservacin de los mismos, as como tambin proporcionar los servicios de mantenimiento y reparacin; entendindose por recursos informticos todo lo relacionado al hardware, software y licencias. A. Identificacin de Necesidades La Unidad solicitante deber justificar ampliamente la necesidad de su requerimiento para la obtencin y uso de un equipo de cmputo, accesorios, software y licencia realizando los siguientes pasos: 1. Identificar y justificar sus necesidades de recursos informticos mediante la definicin de las actividades o tareas a realizar con ellos. 2. Elaborar y presentar la solicitud, a la Gerencia General Administrativa o a la Unidad de Adquisiciones y Contrataciones Institucional (U.A.C.I.), para tramitar el desarrollo de la automatizacin de procesos o la adquisicin de bienes, respectivamente. 3. La Gerencia General Administrativa y la U.A.C.I. con base en la solicitud presentada requerirn un Anlisis Tcnico a la Unidad de Informtica. 4. La Unidad de Informtica programar y realizar una evaluacin y anlisis tcnico de los requerimientos y necesidades presentadas por la Unidad solicitante, tomando en cuenta la racionalizacin de recursos y la disponibilidad presupuestaria correspondiente, as como tambin con base en el plan de desarrollo informtico institucional vigente y la prioridad y urgencia del requerimiento, presentar a la Gerencia General Administrativa o a la UACI, sus conclusiones en un Informe Tcnico para sugerir o no la factibilidad de desarrollo inmediato de la automatizacin de procesos o la compra o distribucin del equipo de cmputo, accesorio, software o licencia solicitado. En el Informe Tcnico al menos deber incluir, segn sea el caso, el estudio de factibilidad de desarrollo de la automatizacin de procesos, la recomendacin respectiva para la compra, las caractersticas o especificaciones tcnicas de los recursos, las cantidades necesarias y disponibles de cada uno; as como los muebles y accesorios para la proteccin y conservacin de los equipos. En aquellos casos en que la Unidad de Informtica cuente dentro de sus inventarios con recursos informticos depositados en trnsito (reparados y sustituidos por nuevos en las unidades); en el Informe Tcnico que emita deber expresarlo para que la UACI no realice el trmite de compra y el requerimiento sea satisfecho con dicho recurso. 5. La UACI, presentar a la Gerencia General Administrativa las recomendaciones propuestas por la Unidad de Informtica para solventar el requerimiento de la Unidad Solicitante. 6. La Gerencia General Administrativa revisar las recomendaciones presentadas y segn sea el caso, instruir a la Unidad de Informtica la realizacin del proceso de planificacin y desarrollo de la automatizacin de procesos o la inclusin de la solicitud en el plan de desarrollo informtico Institucional; y a la Unidad de Adquisiciones y Contrataciones, la realizacin del proceso de compra, o distribucin de bienes o la inclusin de la solicitud en un plan de compras o distribucin de bienes para el siguiente ao. B. Adquisicin de Hardware, Software y Licencias 1. Recomendacin de compra La recomendacin de compra de hardware nuevo o por sustitucin, accesorio, software o licencia estar bajo la responsabilidad de la Unidad de Informtica de la Corte Suprema de Justicia, en conjunto con la Unidad solicitante y la autorizacin de la Gerencia General Administrativa, con base en un anlisis tcnico previo, por lo que la UACI deber solicitar a la Direccin Financiera Institucional la provisin presupuestaria correspondiente. 2. Compra de Hardware, software y Licencias La compra se realizar bajo el siguiente procedimiento: a) La Unidad de Adquisiciones y Contrataciones Institucional gestionar la compra conforme al Informe Tcnico emitido por la Unidad de Informtica del equipo, accesorio, software o licencia, ya sea por Libre Gestin, por Licitacin pblica o privada o por Contratacin directa, esto dependiendo del valor y la cantidad del hardware, software o Licencias requeridos, as como tambin de las causas extraordinarias que motiven dicha compra. b) Por la naturaleza del bien, si el tipo de adquisicin es por libre gestin, la UACI, realizar comparacin de calidad y precios, con un mnimo de tres ofertantes, tomando en cuenta las condiciones y especificaciones tcnicas previamente definidas y las disposiciones consignadas en la Ley de Adquisiciones y Contrataciones de la Administracin Pblica. c) En el caso de que la adquisicin sea por Licitacin ya sea pblica o privada, la UACI elaborar y adecuar en conjunto con la Unidad de Informtica y la Unidad solicitante las bases de licitacin o de concurso conforme a lo estipulado en la Ley. d) En el caso de que la contratacin se haga en forma directa, la Gerencia General Administrativa ser la que consignar mediante resolucin razonada la decisin de realizarla, con base en el dictamen que la Unidad de Informtica emita, ya sea porque as lo exige la proteccin de los derechos de propiedad industrial o intelectual o por las otras razones consignadas en la Ley. 3. Evaluacin de Ofertas a) La evaluacin de ofertas ser realizada por la UACI en el caso de Libre gestin y adjudicacin directa y con el apoyo de la Unidad de Informtica o de la Comisin de Evaluacin de Ofertas, en el caso de Licitacin pblica o privada, la cual estar constituida por El Jefe de la UACI o la persona que l designe, un representante de la Unidad solicitante, un Analista Financiero y un representante de la Unidad de Informtica, para realizar la evaluacin de ofertas presentadas sobre los aspectos tcnico y econmico-financiero, con base en los criterios de evaluacin establecidos en las bases de licitacin o concurso y lo estipulado por la Ley. b) Concluida la evaluacin de las ofertas, cualquiera que fuere el tipo de adquisicin, la UACI con apoyo de la Unidad de Informtica o la Comisin de Evaluacin de Ofertas, elaborar un Informe y un Acta de Adjudicacin recomendando la adjudicacin al suministrante que tenga la oferta mejor calificada o declarar desierto el concurso o licitacin; documentos que debern ser firmados por los responsables de su elaboracin o por los miembros de la Comisin. 4. Adjudicacin de Ofertas Si la Gerencia General Administrativa estuviere de acuerdo con la recomendacin formulada, adjudicar la contratacin; de lo contrario consignar y razonar por escrito su decisin optando por alguna otra o declarar desierto el concurso o licitacin; resolucin que quedar en firme hasta realizada la notificacin correspondiente y transcurrido el plazo que seala la Ley. 5. Contratacin y Recepcin de Bienes o Servicios a) Realizado el proceso de adjudicacin, la UACI proceder a la elaboracin del Contrato de acuerdo a lo estipulado en la ley y para cada tipo de adquisicin. b) Contratado el suministro y atendiendo a una programacin, el Suministrante entregar en el plazo estipulado al Almacn General de la U.A.C.I. el equipo de cmputo, accesorio, software o licencia requerido; por lo que el Almacn deber notificar por anticipado a la Unidad de Informtica, para que sea sta la que proporcione la oportuna asistencia tcnica a fin de garantizar que los recursos informticos por recibir estn conforme a las especificaciones y caractersticas tcnicas contenidas en el Contrato u Orden de Compra. 6. Distribucin de los Bienes a) Para la distribucin del bien adquirido, es requisito indispensable que sea previamente codificado por la Seccin de Activo Fijo e inventariado por la Unidad de Informtica, a efecto de contar con registros confiables de la asignacin, localizacin fsica, fecha de instalacin, etc.; a fin de considerarlo en la programacin de su mantenimiento preventivo y correctivo y la deduccin de responsabilidades en caso de dao o prdida. b) Realizado el registro y codificacin del bien informtico, el Almacn distribuir el equipo y accesorio adquirido ya sea entregndolo directamente a la Unidad solicitante o mediante la colaboracin del Departamento de Servicios Generales con su flota de transporte, informando a la Unidad de Informtica sobre la entrega para efectos de control. Adquirido el bien no se podr modificar su destinatario sin autorizacin de la Gerencia General Administrativa. c) Respecto al software o licencia adquirido, sea por compra o donacin, el Almacn informar a la Unidad de Informtica para que lo retire, quedando bajo su responsabilidad y custodia el respectivo registro, control interno y posterior instalacin y entrega de la copia del certificado de licencia a la Unidad beneficiaria. C. Registro y Control La Gerencia General Administrativa velar porque en la Institucin se cuente con un registro y control confiable y actualizado de todos los bienes muebles propiedad del rgano Judicial (Activo Fijo) a partir de los que la Unidad de Informtica estructurar y mantendr actualizada su propia base de datos amparada en la documentacin correspondiente, en la cual deber reflejarse, al menos: la Unidad Organizativa que lo solicit, el nombre del funcionario a quien le ha sido asignado el bien, la ubicacin fsica, la fecha de compra, distribucin e instalacin de copias, la marca, modelo y nmero de serie del bien, el tiempo de garanta, el tipo de licencia, etc.; con el objeto de producir informes peridicos, emisin de estadsticas, control de vigencia y renovacin, as como para efectos de la planificacin anual de compras en armona con el presupuesto institucional y su ejecucin presupuestaria. 1. Mecanismos de Instalacin de Hardware y Software a) Al recibir los suministros La Unidad beneficiaria solicitar a la Unidad de Informtica la instalacin del equipo, accesorio o programa, informando oportunamente para la obtencin del servicio. b) La Unidad de Informtica programar la fecha de instalacin del hardware y/o software con todos sus componentes y se asegurar de que el software instalado posea la licencia para su utilizacin. Para ello entregar copia del Certificado de Licencia a la Unidad a que est asignado el bien. c) Cuando la Unidad solicitante estime innecesario solicitar el servicio de instalacin de los equipos, el software o accesorios adquiridos, por contar con la capacidad instalada para realizar dicho servicio, nicamente informar en forma escrita a la Unidad de Informtica que ya se realiz la instalacin de los recursos, para que se lleve el control respectivo. d) Para las solicitudes de instalacin de software en particular, la Unidad de Informtica verificar su disponibilidad y si se cuenta con l, realizar el procedimiento previo a la recomendacin de compra de un equipo, accesorio, software o licencia. 2. Descargo de Equipo Obsoleto o Inservible. a) Hardware Cuando sea reportado un equipo por fallas en su funcionamiento, la Unidad de Informtica atender dicha solicitud, determinando los repuestos a requerir para su reparacin e informando a la Unidad de Adquisiciones y Contrataciones Institucional para su respectiva compra y si al momento de buscar repuestos o componentes para repararlo o actualizarlo, se encuentra que estn discontinuados o el costo de reparacin es mayor que la compra de un equipo nuevo, entonces dicha accin ser registrada por medio de una Hoja de Reporte Tcnico en la que sugerir el cambio de dicho equipo por uno de mayor capacidad y de tecnologa ms avanzada para sustituir el obsoleto o inservible. La Unidad interesada, solicitar en base a la Hoja de Reporte Tcnico emitida por Informtica, a la Seccin de Activo Fijo, que evale la obsolescencia o declare inservible el bien y luego descargue del inventario de dicha Unidad. Activo Fijo, verificar el estado del bien tomando en cuenta la Hoja de Reporte Tcnico elaborada por la Unidad de Informtica y dependiendo del resultado, lo declarar inservible porque ya no puede actualizarse o repararse; luego lo descargar del inventario de la Unidad a la que est asignado y notificar a la Unidad de Informtica para que actualice su base de datos. Asimismo, se encargar de retirar el equipo obsoleto y lo trasladar a la Bodega Cucumacayn, para su posterior venta como chatarra. La Unidad de Informtica se encargar de recoger los recursos rescatables de aquellos equipos que ya no van a ser utilizados, activndose nuevamente la disponibilidad de ellos para poder utilizarse en otro equipo, incluyndolos en su informe de equipos depositados en trnsito. b) Software y Licencias La Unidad de Informtica se encargar de recuperar las licencias por medio de su certificado, de aquellos equipos que ya no van a ser utilizados, activndose nuevamente la disponibilidad de licencias para poder utilizarse en otro equipo. La Unidad de Informtica, llevar una Base de Datos de bienes informticos de la Institucin, en la cual se registrar las licencias asignadas para controlar que estn siendo utilizadas y que an se encuentren disponibles. D. Servicios de la Unidad de Informtica La Unidad de Informtica prestar servicios tcnicos de apoyo mediante una relacin funcional (no de autoridad) a las Unidades de Organizacin o Tribunales del rgano Judicial, con el propsito de facilitarles en forma efectiva la ayuda tcnica que necesiten, as como en apoyo a sus funciones, deber procurar coordinar y controlar las acciones de las unidades en lo referente a los recursos informticos. Este apoyo tcnico estar orientado a la programacin y anlisis, produccin y diseo grfico, teleinformtica y capacitacin, para el uso y configuracin del hardware, software de fbrica y sistemas de aplicacin diseados por el personal de Programacin de la Unidad de Informtica y que hayan sido instalados en las diferentes Dependencias del rgano Judicial; asimismo, de la actualizacin del software y licencias correspondientes y la asistencia y apoyo necesario en la evaluacin de requerimientos de recursos informticos. 1. Mantenimiento Preventivo y Correctivo Ser necesario darle mantenimiento preventivo y correctivo a todo el equipo de cmputo del rgano Judicial, el cual consta de: a) Limpieza interna y externa del CPU, incluyendo limpieza de toda la Motherboard y sus diferentes tarjetas controladoras; adems, verificacin de Memoria, eliminacin de archivos temporales, verificacin de virus, scandisk y defragmentacin de disco duro; b) Limpieza interna y externa del Monitor; c) Limpieza interna y externa del Mouse, incluyendo limpieza de Rodillos; d) Limpieza interna y externa del Teclado; e) Limpieza externa e interna de Impresor, incluyendo limpieza y calibracin de Cabezales; f) Limpieza externa e interna de UPS; g) Limpieza externa e interna de Reguladores de Voltaje, y h) Si el equipo cuenta con accesorios adicionales, se proporcionar la respectiva limpieza. Para realizar dicho mantenimiento, el personal tcnico de la Unidad de Informtica utilizar los recursos materiales necesarios, los cuales sern provedos por los procedimientos normales de aprovisionamiento de materiales y equipos. En tal sentido, la Unidad de Informtica procurar desconcentrar dichos servicios en oficinas regionales para minimizar el uso del equipo de transporte y los gastos en combustible. Tambin se encargar de la actualizacin, ajuste y reparacin del hardware distribuido en todo el rgano Judicial, respondiendo oportunamente a solicitudes de servicio de las dependencias y tribunales, procurando atenderlas con diligencia y eficiencia, segn la demanda. 2. Programacin y Anlisis Para agilizar todos los procesos a travs de la mecanizacin, se proporcionarn los servicios de anlisis, diseo, programacin e implementacin de sistemas de acuerdo a necesidades dentro del rgano Judicial. 3. Produccin y Diseo Grfico Los servicios de Produccin comprenden los de digitacin y diseo grfico, con los que se brindar apoyo en todo lo concerniente al levantamiento de textos y artes, as como en la trascripcin de extensos documentos y estudios. 4. Teleinformtica Se brindar apoyo con herramientas de sistemas de comunicacin informtica que permiten las actualizaciones oportunas de todos los procesos en el rgano Judicial, estableciendo lineamientos sobre herramientas de comunicacin, medio y modo de empleo para tal efecto. 5. Asistencia Administrativa y Capacitacin Se brindar apoyo en la solucin de necesidades administrativas a todos los servicios de la Unidad de Informtica, as como en la capacitacin al personal del rgano Judicial en los diferentes paquetes de computacin, de acuerdo a las necesidades de los usuarios, estableciendo horarios y distribuyendo manuales de ayuda de tal forma que favorezca el aprendizaje, procurando que cada uno de los paquetes impartidos sean actualizados y de beneficio para la Institucin. Control de calidad de los sistemas informticos La Plataforma de Evaluacin de la Calidad de los Sistemas Identifica las dimensiones, factores y sub-factores de la jerarqua. Los puntos de vista representados en la plataforma se refieren al proyecto (i.e., proyecto de desarrollo, proyecto de mejoras), el sistema (i.e., caractersticas intrnsecas del  HYPERLINK "http://www.monografias.com/trabajos12/elproduc/elproduc.shtml" producto, operacin y  HYPERLINK "http://www.monografias.com/trabajos15/mantenimiento-industrial/mantenimiento-industrial.shtml" mantenimiento de los sistemas) y la utilidad (i.e., la contribucin del sistema). La plataforma de evaluacin de la calidad, se descompone en dimensiones (proyecto, sistema, utilidad), cada una de las dimensiones se descompone en factores y stos a su vez se descomponen en sub-factores; los sub-factores podran eventualmente seguirse descomponiendo, dependiendo del grado de profundidad que se requiera en una determinada evaluacin. Un proyecto sigue un proceso, envuelve algunos agentes y usa ciertas  HYPERLINK "http://www.monografias.com/trabajos11/contrest/contrest.shtml" herramientas. El sistema est compuesto de  HYPERLINK "http://www.monografias.com/trabajos12/elproduc/elproduc.shtml" productos, se comporta a un determinado nivel de desempeo y se implanta en una  HYPERLINK "http://www.monografias.com/Tecnologia/index.shtml" tecnologa determinada. La utilidad establece la correspondencia de los resultados con las necesidades predefinidas para el sistema, evala la utilizabilidad del sistema desde la perspectiva del usuario y aporta una contribucin o beneficio para  HYPERLINK "http://www.monografias.com/trabajos6/napro/napro.shtml" la organizacin y la comunidad al operar el sistema. Cada factor (proceso, agente, y herramientas de la dimensin proyecto) se sub-divide en sub-factores ( HYPERLINK "http://www.monografias.com/trabajos3/gerenylider/gerenylider.shtml" gerencia del proyecto, proceso adecuado, y  HYPERLINK "http://www.monografias.com/trabajos7/herba/herba.shtml" control de calidad). A cada sub-factor se le asignan categoras, e.g., muy bajo, bajo, medio, alto y excelente, que son tiles para clasificar la informacin sobre los sistemas desde una perspectiva de madurez. Proyecto. La dimensin proyecto trata de caracterizar los aspectos de  HYPERLINK "http://www.monografias.com/trabajos11/veref/veref.shtml" eficiencia del proyecto (i.e., habilidad para desarrollar un sistema utilizando ptimamente el  HYPERLINK "http://www.monografias.com/trabajos6/meti/meti.shtml" tiempo, los  HYPERLINK "http://www.monografias.com/trabajos4/refrec/refrec.shtml" recursos, etc.) desde el punto de vista de los productores y gerentes. Proceso. El proceso evala el grado de eficiencia y continuidad del proceso desde el punto de vista de los productores, bsicamente la gerencia del proceso. Consideraciones de gerencia del proyecto (en ciernes, limitado, aceptable, bajo  HYPERLINK "http://www.monografias.com/trabajos14/control/control.shtml" control, optimo): este sub-factor evala las prcticas gerenciales para el proyecto considerando la  HYPERLINK "http://www.monografias.com/trabajos7/plane/plane.shtml" planificacin, la estimacin y el control de las actividades. Proceso adecuado en su definicin y medida (indefinido, rudimentario, germinando, consolidado, completamente definido): este sub-factor evala la definicin del proceso, la  HYPERLINK "http://www.monografias.com/trabajos11/ladocont/ladocont.shtml" documentacin del proceso y su forma de  HYPERLINK "http://www.monografias.com/trabajos15/la-estadistica/la-estadistica.shtml" medicin con propsito de control. Prcticas de control de calidad (informal, en gestacin, aceptable, en progreso, excelente): este sub-factor evala las caractersticas de las actividades de control de calidad en el proyecto (e.g., revisiones,  HYPERLINK "http://www.monografias.com/trabajos12/romandos/romandos.shtml" \l "PRUEBAS" pruebas, prevencin de errores,  HYPERLINK "http://www.monografias.com/trabajos11/metods/metods.shtml" \l "ANALIT" anlisis de los  HYPERLINK "http://www.monografias.com/trabajos15/calidad-serv/calidad-serv.shtml" \l "PLANT" problemas). Agentes. El factor agentes evala la capacidad del  HYPERLINK "http://www.monografias.com/trabajos14/dinamica-grupos/dinamica-grupos.shtml" grupo de trabajo participando en el proyecto, considerando aspectos gerenciales como tcnicos, desde el punto de vista de productores y gerentes. Balance de experiencias y capacidades adecuadas del  HYPERLINK "http://www.monografias.com/trabajos11/fuper/fuper.shtml" personal (sin preparacin, limitado, aceptable, demostrados, consolidados): este sub-factor evala la experiencia del grupo y las habilidades para realizar sus responsabilidades. Coordinacin y cooperacin dentro del grupo (pobre, baja, media, alta, excelente): este sub-factor evala el  HYPERLINK "http://www.monografias.com/trabajos15/liderazgo/liderazgo.shtml" liderazgo, la conformacin del grupo, y la cooperacin en el proyecto. Sentido de logros y reconocimiento (sin reconocimiento, limitado, aceptable, progresando, excelente): este sub-factor evala el grado de  HYPERLINK "http://www.monografias.com/trabajos5/moti/moti.shtml" \l "desa" motivacin del personal que participa en el proyecto. Herramientas. El factor herramientas evala el grado de  HYPERLINK "http://www.monografias.com/trabajos7/doin/doin.shtml" dominio de las  HYPERLINK "http://www.monografias.com/trabajos6/juti/juti.shtml" tcnicas y herramientas utilizadas en el proyecto, considerando lo adecuado para el proyecto, la experiencia, el  HYPERLINK "http://www.monografias.com/trabajos14/mocom/mocom.shtml" entrenamiento y el soporte para las actividades tcnicas, desde el punto de vista de los productores. Dominio de las tcnicas y herramientas (incapacitados, limitado, aceptable, franco progreso, excelente): este sub-factor evala la experiencia y  HYPERLINK "http://www.monografias.com/trabajos6/prod/prod.shtml" productividad al usar las tcnicas y herramientas para producir "software". Tcnicas y herramientas adecuadas (aun no comprobadas, bajo estudio, aceptables, demostradas, consolidadas): este sub-factor evala las herramientas y tcnicas tanto gerenciales como tcnicas (en proceso de seleccin, en proceso de  HYPERLINK "http://www.monografias.com/trabajos13/discurso/discurso.shtml" introduccin en la  HYPERLINK "http://www.monografias.com/trabajos6/napro/napro.shtml" organizacin, controladas), y los resultados de comparaciones con otras tcnicas y herramientas. Soporte y entrenamiento con las tcnicas y herramientas (inexistente, limitado, a peticin, predefinido, excelente): este sub-factor evala lo adecuado del soporte, entrenamiento y documentacin de las tcnicas y herramientas. Sistema. La dimensin sistema busca evaluar los atributos intrnsecos del sistema y el tipo de tecnologa con que se implanta el sistema, desde el punto de vista de operadores, administradores del sistema y gerentes. Producto. El factor producto evala los atributos intrnsecos del sistema, con respecto a la estructura del sistema, su facilidad de comprensin, desde el punto de vista de operadores y administradores de sistema. Comprensin del producto y su documentacin (inexistente, baja, media, alta, excelente): este sub-factor evala varios aspectos relativos al producto tales como que sea completo, conciso, consistente, as como mantenible y que pueda ser probado ("tests"). Consideraciones de calidad del "software" (pobre, aleatoria, adecuada, bajo control, ptima): este sub-factor evala tamao y complejidad del "software", tomando en consideracin su estructura y modularidad. Controles internos (inexistentes, limitados, adecuados, slidos, excelentes): este sub-factor evala lo adecuados y completos que son los controles en el sistema para asegurar la exactitud de los datos, consideraciones de  HYPERLINK "http://www.monografias.com/trabajos/seguinfo/seguinfo.shtml" seguridad para prevenir acceso no autorizado al sistema y aspectos sobre recuperacin en caso de desastres. Desempeo. El factor desempeo evala las caractersticas dinmicas del "software", tales como fiabilidad y eficiencia, desde el punto de vista de operadores administradores de sistema. Eficiencia en el  HYPERLINK "http://www.monografias.com/trabajos14/consumoahorro/consumoahorro.shtml" consumo de recursos (ineficiente, limitada, aceptable, slida, excelente): este sub-factor evala el consumo de tiempo y espacio de  HYPERLINK "http://www.monografias.com/trabajos13/memor/memor.shtml" memoria en el sistema. Operacin adecuada y su  HYPERLINK "http://www.monografias.com/trabajos11/veref/veref.shtml" eficacia (descontrolada, limitada, aceptable, bajo control, excelente): este sub-factor evala la operacin del sistema, la posibilidad de controlar y contabilizar sus resultados y la interoperabilidad del sistema en el  HYPERLINK "http://www.monografias.com/trabajos15/medio-ambiente-venezuela/medio-ambiente-venezuela.shtml" ambiente operativo. Consideraciones sobre fallas en el sistema (una falla se convierte en desastre, gran cantidad de recursos para recuperarse, se recupera sin graves penalidades, fcil de recuperar, recuperacin automtica): este sub-factor evala la confiabilidad y posibilidad de recuperacin del sistema. Tecnologa. El factor tecnologa evala el nivel de dominio y lo adecuado de la tecnologa con que se implanta el sistema, desde el punto de vista de operadores y administradores del sistema. Dominio de la tecnologa (inexistente, limitado, aceptable, extenso, completo): este sub-factor evala la experiencia de los operadores y de aquellos al cargo del mantenimiento en cuanto a la tecnologa con que se implanta el sistema (e.g.,  HYPERLINK "http://www.monografias.com/Computacion/Sistemas_Operativos/" sistemas operativos,  HYPERLINK "http://www.monografias.com/Computacion/Programacion/" lenguajes de programacin, manejadores de  HYPERLINK "http://www.monografias.com/trabajos11/basda/basda.shtml" bases de datos). Adecuada tecnologa (no comprobada, baja, media, alta, resultados demostrables): este sub-factor evala la gerencia de la tecnologa (seleccin, introduccin, control), as como los resultados de comparaciones con otras tecnologas alternativas. Soporte y entrenamiento para operar y mantener con la tecnologa (inexistente, limitado, a peticin, optima, excelente): este sub-factor evala lo adecuado del soporte, entrenamiento y documentacin de la tecnologa. Utilidad. La dimensin utilidad busca evaluar el nivel de satisfaccin con el sistema, as como la contribucin percibida del sistema para la organizacin, desde el punto de vista de usuarios e involucrados en general. Conformidad. El factor conformidad evala la correspondencia del sistema con las necesidades establecidas, desde el punto de vista de los usuarios. Conforme a las necesidades funcionales y lo adecuado de la informacin producida (no se establecen necesidades, limitado, aceptable, conforme a necesidades, supera las necesidades): este sub-factor evala que tan correcta y adecuada es la informacin suministrada por el sistema. Conforme a necesidades no-funcionales, validez de la informacin y su produccin a tiempo (no se considera, limitado, aceptable, conforme a las necesidades, supera las necesidades): este sub-factor evala la exactitud, su entrega a tiempo o rapidez, lo actualizado y la seguridad de la informacin conservada y suministrada por el sistema. Satisfaccin de los usuarios y sus  HYPERLINK "http://www.monografias.com/trabajos5/psicoso/psicoso.shtml" \l "acti" actitudes respecto al sistema (insatisfechos, pobre, aceptable, demostrable, excelente): este sub-factor evala las expectativas del usuario y sus resultados al usar el sistema. Utilizabilidad. El factor utilizabilidad evala la facilidad de  HYPERLINK "http://www.monografias.com/trabajos5/teap/teap.shtml" aprendizaje y uso del sistema, desde el punto de vista de los usuarios. Sistema discernible (inconsistente, poco amigable, aceptable, fcil manejo, excelente manejo): ste sub-factor evala las caractersticas de la interaccin entre los seres humanos y el sistema, tales como la interfaz, el asesoramiento suministrado por el sistema para orientar las labores del usuario, y la facilidad de recordar aspectos ya suministrados al sistema. Eficiencia de uso (ineficiente, presenta redundancia, aceptable, previene los errores y seala su seriedad, excelente): ste sub-factor evala el esfuerzo requerido para utilizar el sistema. Aprendizaje del sistema (muy compleja, requiere mucho tiempo de aprendizaje, aceptable, aprendizaje rpido, aprendizaje optimo): ste sub-factor evala el esfuerzo requerido para aprender la aplicacin. Contribucin. El factor contribucin evala los beneficios suministrados por el sistema a la organizacin y a la comunidad, desde el punto de vista de los usuarios, promotores y todos los afectados por el sistema. Impacto a los usuarios y su trabajo (sin impacto, pobre, aceptable, gran impacto, excelente): este sub-factor evala el incremento de productividad al usar el sistema. Costo-beneficio con respecto a lo planificado (no se planifica, limitado, aceptable, demostrable, excelente): este sub-factor evala los parmetros econmicos para definir el incremento del  HYPERLINK "http://www.monografias.com/trabajos14/nuevmicro/nuevmicro.shtml" valor adicional del negocio y la recuperacin de la  HYPERLINK "http://www.monografias.com/trabajos12/cntbtres/cntbtres.shtml" inversin. Encaje del sistema en la organizacin y su impacto (no contribuye, limitado, aceptable, gran impacto, excelente): este sub-factor evala las ventajas competitivas al usar el sistema y el  HYPERLINK "http://www.monografias.com/trabajos15/llave-exito/llave-exito.shtml" xito logrado hacia el alcance de las metas estratgicas del negocio. Control de sistemas de informacin El Control de Sistemas e Informtica, consiste en examinar los recursos, las operaciones, los beneficios y los gastos de las producciones (servicios y/o productos de los Sistemas Informticos), de los Organismos sujetos a control, con la finalidad de evaluar la eficacia y eficiencia Administrativa Tcnica y/u Operacional de los Organismos, en concordancia con los principios, normas, tcnicas y procedimientos normalmente aceptados. Asimismo de los Sistemas (Planes, Programas y Presupuestos, Diseo, Software, Hardware, Seguridad, Respaldos y otros) adoptados por la Organizacin para su dinmica de Gestin en salvaguarda de los Recursos del Estado. Existe otra definicin sobre el "control tcnico" en materia de Sistemas e Informtica, y esta se orienta a la revisin del Diseo de los Planes, Diseos de los Sistemas, la demostracin de su eficacia, la Supervisin compulsa de rendimientos, Pruebas de Productividad de la Gestin - Demanda llamada "Pruebas intermedias", el anlisis de resultados, niveles y medios de seguridad, respaldo, y el almacenamiento. As mismo medicin de la vida til del Sistema Informtico adoptado por la Organizacin bajo control. Desarrollo de sistemas Ciclo de vida del desarrollo de sistemas El desarrollo de sistemas es un proceso que consiste en dos etapas principales de anlisis y diseo de sistemas; comienza cuando la gerencia, o en algunas ocasiones el personal de desarrollo de sistemas, se da cuenta que cierto sistema del negocio necesita mejorarse. El ciclo de vida del desarrollo de sistemas es el conjunto de actividades de los analistas, diseadores y usuarios, que necesitan llevarse a cabo para desarrollar y poner en marcha un sistema de informacin. Se debe tener presente que en la mayora de las situaciones del negocio, las actividades estn ntimamente relacionadas y son inseparables. El ciclo de vida del desarrollo de sistemas consiste en las siguientes actividades: 1. Investigacin preliminar 2. Determinacin de requerimientos 3. Desarrollo de sistema prototipo 4. Diseo de sistema 5. Desarrollo de software 6. Prueba de los sistemas 7. Puesta en marcha Investigaciones preliminares Cuantas veces se est en situaciones en donde se pregunta si no existe una mejor manera de hacer algo? Por ejemplo, abrir una tienda departamental adicional que crear una necesidad para nuevos procedimientos de facturacin, cuando un alto porcentaje de clientes utiliza la cuenta de crdito de esta compaa de esta compaa y compra en todas las tiendas. Duplicar el nmero de clientas para agrandar las instalaciones y la introduccin de muchos nuevos productos, puede traer nuevos requerimientos de pago e cuentas. Un cambio en las reas de los gerentes departamentales puede guiarlos hacia nuevas formas para registrar las ventas, con implicaciones para el sistema de entrada de pedidos basado en computadora. Una compaa en crecimiento, puede contemplara los sistemas de informacin computarizados como una forma para hacer posible el crecimiento continuo, sin tener dificultades en el proceso de los pedidos de los clientes. Se puede inicias una peticin por muchas razones, pero la clave es que alguien, ya sea gerente, un empleado o un especialista de sistemas, inicie un requerimiento para recibir ayuda de un sistema de informacin. Cuando ese requerimiento se realiza, la primera actividad de sistemas, es decir, la investigacin preliminar, se inicia. Esta actividad tiene tres partes: clasificacin de requerimiento, estudio de la factibilidad y aprobacin del requerimiento. El resultado ser aprobar el requerimiento para la atencin posterior o rechazarlo como no factible para un desarrollo futuro. Clarificacin del requerimiento En las empresas muchos requerimientos de los empleados y usuarios no estn establecidos claramente; por lo tanto, antes de que pueda considerarse la investigacin del sistema, le proyecto requerido debe examinarse para determinar para determinar precisamente lo que desea la empresa. Una simple llamada telefnica puede ser suficiente si la persona que requiere el servicio tiene una idea clara, pero no sabe cmo establecerla. Por otro lado, la persona que hace el requerimiento puede estar simplemente pidiendo ayuda sin saber qu es lo que est mal o por qu existe un problema. La clarificacin del problema es este caso, antes de poder llagar a otro paso, el requerimiento de proyecto debe estar claramente establecido. Estudio de Factibilidad Un resultado importante de la investigacin preliminar es la determinacin de que el sistema requerido es factible. Existen tres aspectos en el estudio de factibilidad de la investigacin preliminar: 1. Factibilidad tcnica. Puede realizarse el trabajo para el proyecto con el equipo actual, tecnologa de software y el personal disponible? Si se requiere nueva tecnologa, qu probabilidades hay de que pueda desarrollarse? 2. factibilidad econmica. Existen suficientes beneficios en la creacin del sistema para hacer que los costos sean aceptables? O, en forma inversa, son tan altos los costos como para que el proyecto no deba llevarse a cabo? 3. Factibilidad operativa. Se utilizar el sistema si se desarrolla y pone en marcha? Habr resistencia de los usuarios, que los posibles beneficios reducirn del sistema. El estudio de factibilidad se lleva a cabo con un pequeo grupo de gente, familiarizada con las tcnicas de los sistemas de informacin, que entienden la parte de la empresa que ser afectada por el proyecto y tienen los conocimientos suficientes del proceso de anlisis y diseo de sistemas. Aprobacin del requerimiento No todos los proyectos requeridos son deseables o factibles. Sin embargo, aquellos que son tanto factibles como deseables deben anotarse para tomarlos en cuenta. En algunos casos, el desarrollo puede comenzar inmediatamente, pero en la mayor parte, los miembros del departamento de sistemas estn ocupados en otros proyectos que se encuentran en marcha. Cuando esto sucede, la gerencia decide que los proyectos son ms importantes y entonces los programas. Despus de que se aprueba la requisicin de un proyecto, se estima su costo, la prioridad, el tiempo de terminacin y los requerimientos del personal que se utilizan, para determinar qu lista existente los proyectos se incluir. Posteriormente, cuando se terminan algunos proyectos anteriores, puede iniciarse el desarrollo de la aplicacin propuesta. En este momento, comienza la recabacin de datos y la determinacin de los requerimientos. Determinacin de requerimientos El punto clave de anlisis de sistemas se consigue al adquirir un conocimiento detallado de todas las facetas importantes dentro del rea de negocios que se investiga. (Por esta razn, a menudo esta actividad se conoce como investigacin detallada.) Los analistas, al trabajar con los empleados y gerentes, deben estudiar el proceso que actualmente se efecta para contestar estas preguntas clave: 1. Qu se est haciendo? 2. Cmo se est haciendo? 3. Qu tan frecuentemente ocurre? 4. Qu tan grande es la cantidad de transacciones o decisiones? 5. Qu tan bien se lleva acabo la tarea? 6. Existe algn problema? 7. Si el problema existe, qu tan serio es? 8. Si el problema existe, cul es la causa principal? Para contestar estas preguntas, los analistas de sistemas hablarn con diferentes personas para recabar los detalles en relacin con el proceso, as como sus opiniones sobre las causas por las cuales suceden las cosas de esa manera y algunas ideas en relacin a modificarlas. Se utilizan cuestionarios para recopilar esta informacin, aplicndolos a grandes que no pueden entrevistarse en forma individual. Las investigaciones detalladas tambin requieren el estudio de manuales y reportes, la observacin real de las actividades de las actividades de trabajo y algunas veces la recabacin de formas y documentos para entender completamente el proceso. Conforme se recopilan los elementos, los analistas estudian los requerimientos de datos para identificar las caractersticas que tendr el nuevo sistema, incluyendo la informacin que el sistema debe producir y las caractersticas operativas, como son controles de procesamiento, tiempos de respuesta y mtodos de entrada y salida. Desarrollo del sistema prototipo La preparacin de prototipos es el proceso de crear, desarrollar y refinar un modelo funcional del sistema final. Se puede crear un modelo prototipo preliminar durante la etapa de definicin del problema. Un miembro del equipo de reconocimiento -suponga que se trata de un especialista en el procesamiento de datos- puede construir un modelo de este tipo que muestre la composicin de las pantallas y los formatos de los informes. Durante una sesin de requerimientos, otros miembros del equipo y usuarios del futuro sistema examinan esta muestra en la forma con el constructor del modelo entiende en principio el problema y los resultado que debe producir el sistema. En este momento puede iniciarse un proceso de refinacin si los usuarios sealan omisiones y equivocas. Durante este proceso de refinacin, cuyo objetivo es definir la necesidad que existe, uno o ms miembros del equipo pueden utilizar una computadora personal y un paquete de programas de prototipos a fin de crear una serie de pantallas en la computadora personal. Estas pantallas no son las salidas que producen los programas ya terminados, pero pueden parecerse mucho a esos resultados. Es posible exhibir en el monitor de la computadora, como una secuencia de diapositivas, mens de captura de datos, la interfaz con el usuario debe servir para buscar, consultar y manipular datos y el formato de los informes de salida. Por ejemplo, se pueden simular los resultados de una serie de selecciones hechas en mens para que los usuarios tengan una idea ms clara de la forma como el constructor o los constructores del sistema estn interpretando el problema. Si los usuarios no estn convencidos de lo que se exhibe define con precisin sus necesidades, pueden modificar fcilmente las plantillas prototipo hasta que estn satisfechos. La creacin de un modelo preliminar de prototipo en este punto produce varios beneficios: los usuarios pueden ver que se est avanzado, se les motiva para que participen activamente en la definicin del problema, se mejora la comunicacin 4entre todas las partes interesadas y se aclaran los equvocos en una etapa temprana del estudio de sistemas, antes de que se conviertan en costosos errores. Como se acaba e ver, puede ser necesario un proceso repetitivo (o interactivo) para terminar el paso de definicin del problema. No existe un procedimiento definido que se deba seguir antes de que se pueda iniciarse el anlisis detallado del sistema. Un alto ejecutivo puede creer que existen diferencias de informacin. Puede preparar una declaracin general de los objetivos y nombrar a un gerente para que realice un reconocimiento. Pueden realizarse varias sesiones de requerimientos para traducir los deseos generales a objetivos ms especficos. Asimismo, pueden crearse y refinarse modelos preliminares de prototipo; se puede ampliar o reducir el alcance del estudio y es posible tambin que cambien los objetivos conforme se renan los datos. Una vez que parezca haberse logrado la aprobacin en cuanto a la definicin del problema, el equipo de reconocimiento deber poner la definicin detallada por escrito y enviarla a todas las personas interesadas, las cules debern aprobarla tambin por escrito. Si persisten diferencias, debern resolverse en sesiones adicionales de requerimientos. Hay quienes se impacientan con los retrasos en el desarrollo del sistema causados por estas sesiones adicionales. Sin embargo, las personas ms prudentes saben que los retrasos verdaderamente largos y costosos se presentan cuando los usuarios descubren, ya muy avanzados el proceso del desarrollo, que el sistema diseado no es satisfactorio por haberse pasado por alto algunos requerimientos. Diseo del sistema El diseo de un sistema de informacin produce los elementos que establecen cmo el sistema cumplir los requerimientos indicados durante el anlisis de sistemas. A menudo los especialistas de sistemas se refieren a esta etapa como en diseo lgico, encontraste con desarrollo del software de programas, que se conoce como diseo fsico. Los analistas de sistemas comienzan por identificar los informes y otras salidas que el sistema producir. A continuacin los datos especficos con stos se sealan, incluyendo su localizacin exacta sobre el papel, la pantalla de despliegue u otro medio. Usualmente, los diseadores dibujan la forma o la visualizacin como la esperan cuando el sistema esta terminado. El diseo del sistema tambin describe los datos calculados o almacenados que se introducirn. Los grupos de datos individuales y los procedimientos de clculo se describen con detalle. Los diseadores seleccionan las estructuras de los archivos y los dispositivos de almacenamiento, como son discos magnticos, cintas magnticas o incluso archivos en papel. Los procedimientos que ellos escriben muestran cmo se van a procesar los datos y a producir la salida. Los documentos que contienen las especificaciones de diseo utilizan muchas formas para representar los diseos, diagramas, tablas y smbolos especiales, algunos de los cuales el lector puede haber utilizado ya y otros que pudieran ser totalmente nuevos. La informacin del diseo detallado se pasa al grupo de programacin para que pueda comenzar el desarrollo del software. Los diseadores son responsables de proporcionar a los programadores las especificaciones completas y escritas con claridad, que establezcan lo que debe hacer el software. Conforme comienza la programacin, los diseadores estn pendientes para contestar preguntas, esclarecer ideas confusas y manejar los problemas que confronten los programadores cuando utilicen las especificaciones de diseo. Desarrollo del Software Los desarrollares del software pueden instalar o modificar; por ejemplo, software comercial que se haya comprado, o pueden escribir programas nuevos diseados a la medida. La decisin de qu se va a hacer depende del costo de cada una de las opciones, el tiempo disponible para describir el software y la disponibilidad de programadores. En forma usual, en las grandes empresas los programadores de computadoras (o la combinacin de analistas-programadores) son parte del grupo profesional permanente. Las compaas ms pequeas en donde los programadores permanentes no se han contratado, pueden obtener servicios externos de programacin con base en un contrato. Los programadores tambin son responsables de documentar el programa e incluir los comentarios que expliquen tanto cmo y por qu se utilizo cierto procedimiento conforma se codifico de cierta forma. La documentacin es esencial para probar el programa y darle mantenimiento una vez que la aplicacin se ha puesto en marcha. Prueba de los sistemas Durante la prueba, el sistema se utiliza en forma experimental para asegurar que el software no falle; es decir, Que corra de acuerdo a sus especificaciones y a la manera que los usuarios esperan que lo haga. Se examinan datos especiales de prueba en la entrada del procesamiento y los resultados para localizar algunos problemas inesperados. Puede permitirse tambin a un grupo limitado de usuarios que utilice el sistema, de manera que los analistas puedan captar si tratan de utilizarlo en forma no planeadas. Es preferible detectar cualquier anomala antes de que la empresa ponga en marcha el sistema y dependa de l. En muchas compaas la prueba se lleva a cabo por personas diferentes a aquellos que los escriben en forma original; es decir si se utilizan personas que no conocen como se disearon ciertas partes de los programas, se asegura una mayor y ms completa prueba, adems de ser imparcial, lo que da a un software ms confiable. Puesta en marcha Cuando el personal de sistemas verifica y pone en uso el nuevo equipo, entrena al personal usuario; instala la nueva aplicacin y constituye los archivos de datos que se necesiten, entonces el sistema est puesto en marcha. De acuerdo con el tamao de la empresa que emplear la aplicacin y el riesgo asociado con su uso, los desarrolladores del sistema pueden escoger una prueba piloto para la operacin del sistema solamente en un rea de la compaa; por ejemplo, en un departamento o slo con una o dos personas. A veces corrern en forma paralela tanto el sistema anterior como el nuevo para comparar los resultados de ambos; en otras situaciones, los desarrolladores pararn por completo el sistema anterior un da y al siguiente empezarn a utilizar el nuevo. Como se puede apreciar, cada estrategia para la puesta en marcha tiene sus mritos, que dependen de la situacin del negocio considerado. Sin importar la estrategia para la puesta en marcha que se haya utilizado, los desarrolladores tendrn que asegurarse que el uso inicial del sistema est libre de problemas. Una vez instalada, con frecuencia la aplicacin se utiliza por muchos aos; sin embargo, tanto la empresa como los usuarios cambiarn, y el medio ambienta ser diferente tambin a travs del tiempo. Por lo tanto, la aplicacin indudable mente necesitar mantenimiento; es decir, se harn cambios y modificaciones al software, y a los archivos o procedimientos para cubrir los requerimientos nuevos de los usuarios. Los sistemas de la empresa y el medio ambiente de los negocios estn en continuo cambio. Los sistemas de informacin deben mantenerse de la misma forma; es este sentido, la propuesta en marcha es un proceso continuo. Anlisis y Diseo Investigacin preliminar Determinacin de requerimientos Desarrollo del sistema prototipo Diseo del sistema Desarrollo del sistema Prueba del sistema Puesta en marcha Adquisicin de Sistemas de Software La intuicin puede ser una buena forma de afrontar la adquisicin de un proyecto de software por parte de una empresa. Algunos pocos factores son clave para el desarrollo. Las empresas de sistemas de software dan, o deberan dar, un cierto miedo a sus clientes porque trabajan con probabilidades muy altas de fracaso. Las estadsticas y los grficos de los informes anuales de nuestro sector estn resultando tan tozudos como contundentes, y a pesar de los conocimientos tericos sobre procesos y calidad, se resisten a cambiar. Como los sistemas de software resuman tcnica, lo normal es que los clientes no sean expertos, y de no ser empresas de cierta envergadura con departamentos informticos propios, o de no contar con un servicio de asesora especializado en procesos de adquisicin de software (que son muy difciles de identificar), suelen gestionar la seleccin del proveedor, y dems tareas del proceso de adquisicin (ISO/IEC 12207 5.1) con una mezcla de suerte e intuicin.  INCLUDEPICTURE "http://www.versioncero.com/images/179.gif" \* MERGEFORMATINET  Para afrontar la adquisicin de un sistema de software los clientes se suelen apoyar en tres estrategias: Asesora profesional para la adquisicin de software. Currculum del proveedor (certificaciones oficiales, experiencia). La mencionada intuicin. Y aunque esta ltima pudiera parecer la menos rigurosa o profesional, bien guiada puede ser la ms til de las tres. Los proyectos problemticos son una manifestacin ms del  HYPERLINK "http://es.wikipedia.org/wiki/Principio_de_Pareto" Principio de Pareto: la mayor parte de sus problemas proceden directa o indirectamente de un nmero muy reducido de causas, y con un poco de olfato o de intuicin se pueden detectar con bastante puntera. Las otras dos estrategias tambin son efectivas, aunque convendra observar algunos consejos para esquivar los errores comunes, que las pueden mudar en ineficaces o contraproducentes; pero por ser limitada la extensin que se espera de un artculo, ser ms provechoso dedicar este a la intuicin, empezando as por el factor fuerte de Pareto; y dejando a las otras dos como temas para posteriores artculos, que podran cerrarlo a modo de triloga. INTUICIN Las primeras respuestas que se busca en cada nuevo proyecto son: El cliente sabe realmente qu es lo que quiere conseguir o mejorar? Sabe lo que necesita?, o en caso contrario Sabe que no lo sabe, y que sta es su principal prioridad? Los presupuestos, estimaciones, charlas, reuniones y en general las conversaciones que se han mantenido con l estaban encaminadas a medir la profundidad del futuro sistema, a conocer el mbito del problema que tiene que solucionar el software, y el nivel de anlisis que ya ha realizado el cliente?; o por el contrario su objetivo ha sido no dejarle enfriar y conseguir que firme en un contrato una operacin de la que no se tiene claro su alcance. El cliente va a colaborar con el equipo durante el proyecto?, o ha hecho el pedido y se ha quedado a esperar el da de la entrega. Estos son los factores clave o los que podramos llamar factores de Pareto. Cuando se gestionan bien, los proyectos no suelen fracasar. Por el contrario, cuando surgen problemas, la mayor parte tienen origen directa o indirectamente en una de estas tres causas: Clientes que buscan programas. Proveedores que buscan dinero. Clientes que no se implican en el proyecto. 1.- Clientes que buscan programas. Los clientes que buscan programas dan una orientacin a las tareas de adquisicin que atrae factores de riesgo hacia el proyecto. Sin duda los clientes no necesitan programas. Necesitan soluciones. Aunque a primera vista esto pueda parecer un simple juego dialctico, lo cierto es que esta diferencia de enfoque transmite implicaciones importantes al proyecto. Si lo que el cliente quiere es una pgina web, es posible que su proveedor le entregue una ms o menos bonita, pero lo que no sabemos es si con ella mejorar la calidad en la atencin a sus clientes, o se reducirn las llamadas al centro de soporte telefnico, o recibir feed-back del mercado, o Cuntas empresas han comprado un CRM o un ERP que funciona, pero que no han conseguido las mejoras que se esperaban? En los proyectos de clientes que quieren programas se suelen descuidar actividades clave como el anlisis del problema, de los requisitos del sistema, el estudio y comparacin de las posibles opciones de solucin, o de los criterios que se emplearn para la validacin y verificacin del producto generado. La Ingeniera del Software y la experiencia conocen muy bien las consecuencias de estos descuidos. 2.- Proveedores que buscan dinero. Hay empresas (no slo de software) que tienen como objetivo aportar beneficios o valor a los clientes a travs de sus sistemas, y la consecuencia de ese trabajo es una facturacin directamente proporcional al nmero de clientes y a la cantidad de valor proporcionado. Otras tienen como objetivo ganar dinero, y para conseguirlo venden productos o servicios a sus clientes. Tambin aqu puede parecer que se trata de una misma cosa, vista desde ngulos diferentes; pero no es as. Quiz en otros negocios las consecuencias de uno u otro enfoque no sean muy significativas, pero en el nuestro cada una de estas visiones transmite implicaciones muy importantes a los proyectos, y los puede predisponer al fracaso. El primer tipo de empresa forma a su personal, mide sus resultados, elabora su estrategia y su tctica para conseguir que los negocios de sus clientes triunfen, sabiendo que de esta forma cada vez ganar ms dinero. En el segundo tipo de empresa la estrategia, la medicin de sus procesos y sus esfuerzos se dirigen a aumentar las cifras de ventas, pero no a solucionar los problemas de los clientes. Las consecuencias de trabajar con la segunda estrategia suelen ser: Las estimaciones de precio y agendas responden a razones estratgicas, no a la realidad del sistema. El anlisis y la gestin de los requisitos se realizan de forma inadecuada. Se acaban desbordando agendas y presupuestos. Se inyecta presin al proyecto. Se generan sistemas de baja calidad: tasas de errores altos, arquitecturas parcheadas o diseos para salir del paso Las deficiencias de los requisitos hacen difcil validar y verificar los productos obtenidos 3.- Clientes que no se implican en el proyecto. El descubrimiento temprano de desviaciones sobre la planificacin, de modificaciones o sugerencias no descubiertas en los requisitos iniciales es la mejor estrategia para evitar el re-trabajo y conseguir una eficiencia alta en el proyecto. Por muy bien que se haya realizado el anlisis de requisitos del sistema y del software, cuando el cliente vea el resultado descubrir atributos o funcionalidades que no se han implementado como l esperaba, o que necesitan algunas ampliaciones que no se consideraron al principio. Como resultado se terminan descubriendo en el momento ms caro del ciclo de desarrollo: en la validacin del sistema. Los desencuentros en ese momento suelen generar recelos entre cliente y proveedor, de mayor o menor calado, que en ocasiones terminan como el rosario de la Aurora. Trminos de Referencia Para cada necesidad particular, existe una serie de trminos de referencia los cuales deben de ser bien conocidos antes de iniciar un proceso de contratacin o de desarrollo. Parte de los trminos de referencia son los requerimientos funcionales los cuales definen el comportamiento del software, pero tambin existen requerimientos no funcionales muy importantes que deben de tomarse en cuenta para definir estos trminos de referencia. Un caso por ejemplo lo conforman la plataforma del sistema la cual est compuesta por el Hardware (arquitectura) y el Sistema Operativo. Existen tres plataformas que son las ms utilizadas en la actualidad, empezando por plataformas Microsoft que utilizan equipos IBM compatibles, seguidos de plataformas Linux que tambin pueden correr en los mismos equipos y finalmente estn las plataformas de Apple con su Sistema Operativo MacOS X. En el mercado pueden existir muchas opciones para una necesidad funcional particular, pero para una plataforma especfica podra haber pocas opciones o del todo ninguna. Hasta el momento hay una tendencia en el mercado de que las plataformas Linux trabajan bajo esquemas de Software Libre y por lo tanto la mayora de sistemas que existen para esta plataforma tambin funcionan en esquemas similares. Por el contrario, en plataformas de Microsoft Windows hay una mayor cantidad de opciones comerciales para productos enlatados aunque esto no quiere decir que esto es una norma sino ms bien una tendencia. Tipos de contratacin Una vez que se han definido todos los trminos de referencia, sigue un proceso de bsqueda de soluciones en el mercado (productos enlatados) o bien una bsqueda de recursos para la implementacin de la solucin ya sean internos o externos. Este proceso se define a continuacin. Productos Enlatados Los productos enlatados consisten en programas que ya han sido previamente desarrollados y responden a una solucin particular de un problema. Usualmente se habla de soluciones comerciales, pero tambin se incluye en esta categora al software libre. La ventaja de este tipo de productos es que no se gasta tiempo en desarrollarlo sino que se implementa pero se sacrifica la funcionalidad debido a que a veces las necesidades son mayores y el producto adquirido no las contempla todas. Desarrollo Outsource El desarrollo outsource consiste en contratar a una persona, empresa o grupo de personas para que desarrollen un proyecto de acuerdo a necesidades especficas. Usualmente se les entrega una lista de requerimientos, se les da un tiempo prudencial y el resultado es el software esperado. Esta solucin le puede servir a empresas que no tienen personal informtico o bien donde este personal est sobrecargado de labores y no pueden dedicarle el tiempo a nuevos proyectos. Desarrollo in-house El desarrollo in-house consiste en llevar a cabo todo el proyecto internamente ya sea con recursos informticos o bien usuarios conocedores del problema y las herramientas disponibles para resolverlo. De todas las soluciones esta es la que brindar el mejor resultado ya que al manejarse la solucin internamente se supone que hay un mayor conocimiento de las necesidades y del entorno donde va a correr la aplicacin. No obstante, los proyectos que se desarrollan internamente, usualmente carecen de proyeccin y se exceden en la mayora de casos, de trmites burocrticos para arreglar los problemas que se van encontrando durante todo el proceso de ciclo de vida del sistema. Mantenimiento de Sistemas Se discutir principalmente cuestiones de instalacin y configuracin. Sin embargo, la administracin de un sistema, es mucho ms que esodespus de activar un servicio, tambin se deber mantenerlo en correcto funcionamiento. Para la mayora de stos, ser suficiente con una pequea revisin, pero para otros servicios, como lo son el correo o las noticias, ser necesario ejecutar rutinas de verificacin para mantener el sistema en ptimo estado. La tarea mnima de mantenimiento es comprobar regularmente el sistema y los ficheros de registro de cada aplicacin buscando condiciones de error y eventos inusuales. Por lo general, es posible hacer esto escribiendo un par de scripts de rdenes y ejecutndolos peridicamente mediante la orden cron. Se podr encontrar algunos de estos scripts en distribuciones fuente de algunas aplicaciones importantes como inn o C News. Tras obtenerlos, slo se tendr que retocarlos para adecuarlos a nuestras necesidades y preferencias. La salida de cualquiera de los trabajos de nuestro cron, se debera enviar a una cuenta de administracin. Por defecto, muchas aplicaciones enviarn informes de errores, estadsticas de uso, o resmenes del fichero de registro a la cuenta de root. Esto solo tiene sentido si se entra al sistema como root frecuentemente. Una idea mucho mejor es redirigir el correo de root a nuestra cuenta personal, estableciendo un alias de correo. De todos modos, por muy cuidadoso que sea configurando su mquina, la ley de Murphy garantiza que surgir algn problema en el futuro. Por lo tanto, el mantenimiento de un sistema implica tambin estar disponible para quejas. Generalmente la gente espera que se pueda contactar con el administrador del sistema al menos por correo electrnico, como root. Sin embargo, existen otras denominaciones para direcciones de correo usadas comnmente para contactar a los posibles encargados de la administracin de respectivos servicios del sistema. Por ejemplo, las quejas sobre el mal funcionamiento del correo se dirigirn generalmente al postmaster (encargado del correo). Del mismo modo, los problemas con el sistema de noticias pueden ser comunicados a newsmaster o al usenet. El correo al hostmaster se debera redirigir a la persona encargada de los servicios bsicos de red del nodo, y del servicio de nombres DNS si esta funcionando un servidor de nombres. 1.5.1. Seguridad del Sistema Otro aspecto muy importante de la administracin de sistemas en un entorno de red es proteger al sistema y a sus usuarios, de intrusos. Los sistemas que son administrados descuidadamente ofrecen muchos huecos a los malintencionados: los ataques van desde averiguar las claves hasta acceder a nivel de Ethernet, y el dao causado puede ser desde mensajes de correo falsos hasta prdida de datos o violacin de la privacidad de los usuarios. Se mencionaran algunos problemas concretos cuando se discuta el contexto en el que pueden ocurrir, y algunas defensas comunes contra ellos. En esta seccin se comentarn algunos ejemplos y tcnicas bsicas para poder lidiar con la seguridad del sistema. Por supuesto, los temas relatados aqu no pueden tratar exhaustivamente todos los aspectos de seguridad con los que uno se puede encontrar; sirven meramente para ilustrar los problemas que pueden surgir. Por tanto, la lectura de un buen libro sobre seguridad es absolutamente obligada, especialmente en un sistema en red. La seguridad del sistema comienza con una buena administracin del mismo. Esto incluye comprobar la propiedad y permisos de todos los ficheros y directorios vitales, monitorizar el uso de cuentas privilegiadas, etc. El programa COPS, por ejemplo, sirve para comprobar nuestro sistema de ficheros y ficheros de configuracin generales, en busca de permisos inusuales u otras anomalas. Tambin es conveniente usar un sistema de claves que fuerce ciertas reglas en las claves de los usuarios que las hagan difciles de adivinar. El sistema de claves ocultas (shadow password), por ejemplo, requiere que una clave tenga al menos cinco letras, entre las cuales se encuentren tanto maysculas como minsculas, nmeros y caracteres no-alfabticos. Cuando un servicio se hace accesible a la red, asegrese de darle el menor privilegio. Esto significa, en una palabra que no se debern permitir acciones que no son imprescindibles, para que se trabaje como se dise el servicio originalmente. Por ejemplo, el usuario debera hacer sus programas con setuid root, o alguna otra cuenta privilegiada, slo si realmente se necesitara. Tambin, si se quiere usar un servicio slo para una aplicacin muy limitada, el administrador del sistema no debe vacilar en configurar el servicio tan restrictivamente como la aplicacin especial lo permita. Por ejemplo, si se quiere permitir a mquinas sin disco arrancar desde un nodo en especial, se debe facilitar el servicio TFTP (Trivial File Transfer Protocol de modo que se puedan obtener los ficheros de configuracin bsicos del directorio /boot. Sin embargo, cuando se usa sin restringir, TFTP permite a cualquier usuario de cualquier lugar del mundo leer cualquier fichero de su sistema. Si esto no es lo que desea, luego se debe restringir el servicio TFTP solamente al directorio /boot. Pensando en la misma lnea, se podra restringir ciertos servicios a usuarios que acceden desde ciertos nodos, digamos desde nuestra red local. tcpd, hace esto para una variedad de aplicaciones de red. Se explorarn otros mtodos ms sofisticados para restringir el acceso a nodos o servicios particulares. Otro punto importante a tener en cuenta es evitar software peligroso. Claro que cualquier software que se utilice puede resultar peligroso, dado que el software puede tener fallos que gente astuta pueda explotar para acceder a nuestro sistema. Cosas como sta ocurren, y no hay proteccin segura contra ello. Este problema afecta al software libre y a productos comerciales por igual. De cualquier modo programas que requieran privilegio especial son inherentemente ms peligrosos que otros, ya que cualquier fallo aprovechable en stos puede tener consecuencias desastrosas. Si instala un programa setuid con propsitos de red, sea muy cuidadoso y no deje de leerse toda la documentacin, de manera tal de no crear una brecha en la seguridad del sistema por accidente. Otra fuente a considerar deberan ser aquellos programas que permiten registrarse en el sistema, o la ejecucin de rdenes con autentificacin limitada. Las rdenes rlogin, rsh y rexec, son muy tiles pero ofrecen un muy ligero mtodo de autentificacin para aquellos que hagan uso de ellas. Un mtodo de autentificacin se basa en la confianza del nombre del nodo llamado, el cual fue obtenido de un servidor de nombres, (se hablar de estos ms adelante), que pudo haber sido falseado. Hoy en da, debera ser una prctica comn el reemplazar completamente los comandos r con la coleccin de herramientas ssh. Las herramientas ssh usan un mtodo de autentificacin mucho ms confiable, adems de proporcionar otros servicios como encriptacin y compresin. Nunca se debera de olvidar que nuestras precauciones pueden fallar, por muy cuidadosas que estas sean. Por eso se debera asegurar de que la deteccin de los posibles intrusos es relativamente rpida. Comprobar los ficheros de actividad es un buen comienzo, pero el intruso probablemente sea bastante listo, y borrar cualquier huella que haya dejado. Sin embargo, hay herramientas como tripwire, (escrito por Gene Kim y Gene Spafford),  HYPERLINK "http://www.ibiblio.org/pub/linux/docs/LuCaS/Manuales-LuCAS/GARL2/garl2/x1519.html" \l "FTN.AEN1601#FTN.AEN1601" [4]que permite comprobar ficheros vitales del sistema para ver si sus contenidos o permisos han cambiado. tripwire realiza varias e intensas sumas de verificacin (checksums) sobre estos ficheros y almacena los resultados en una base de datos. En las siguientes ejecuciones, se reevalan y comparan dichas sumas de verificacin con las almacenadas, detectndose as cualquier posible modificacin. Mantenimiento de los sistemas de informacin Con posterioridad a la fase de implementacin de los sistemas, se impone la fase de mantenimiento. El mantenimiento de sistemas es el mantenimiento continuo despus del inicio del funcionamiento. Cuando se elaboran planes para la estrategia de informacin, las organizaciones no pueden dejar de considerar que el mantenimiento de sistemas es la fase ms prolongada y costosa del ciclo de vida de los sistemas. Las implicaciones del volumen de trabajo para mantenimiento para los planes de estrategia de informacin en una organizacin es un tema que merece atencin especial. La estructura de organizacin necesita flexibilidad para apoyar el mantenimiento de los sistemas existentes concurrentemente con la ejecucin de nuevas tecnologas. Es importante considerar la evaluacin y el monitoreo de un sistema en trminos del mantenimiento necesario y, en consecuencia, reducir o contener los costos implcitos. El mantenimiento de sistemas puede clasificarse en cuatro grupos, cada uno de los cuales repercute en el plan estratgico de informacin institucional de diferentes maneras: Mantenimiento correctivo. Independientemente de cun bien diseado, desarrollado y probado est un sistema o aplicacin, ocurrirn errores inevitablemente. Este tipo de mantenimiento se relaciona con la solucin o la correccin de problemas del sistema. Atae generalmente a problemas no identificados durante la fase de ejecucin. Un ejemplo de mantenimiento correctivo es la falta de una caracterstica requerida por el usuario, o su funcionamiento defectuoso. Mantenimiento para fines especficos. Este tipo de mantenimiento se refiere a la creacin de caractersticas nuevas o a la adaptacin de las existentes segn lo requieren los cambios en la organizacin o los usuarios, por ejemplo, los cambios en el cdigo tributario o los reglamentos internos de la organizacin. Mantenimiento para mejoras. Se trata de la extensin o el mejoramiento del desempeo del sistema, ya sea mediante el agregado de nuevas caractersticas, o el cambio de las existentes. Un ejemplo de este tipo de mantenimiento es la conversin de los sistemas de texto a GUI (interfaz grfica de usuarios). '()P Q ! " }~   qrtu679:kh=OJQJ^Jh@IhJBX5OJQJ\^Jh@Ih=lr5OJQJ\^JhJBX5OJQJ\^Jh@Ih=lrOJQJ^JhJBXOJQJ^J&h7[h i5CJOJQJ\^JaJ&h7[hc;5CJOJQJ\^JaJ6()P Q ! " ~ r7<$a$gd@I$[$\$a$gd@I(;<>?mn)*! !L!M!W!!!""$$^%_%%%((h)l),,--P0Q0f2g2448696778999:ȸȸhUOJQJ^Jh@Ih=lr5OJQJ\^JhJBX5OJQJ\^JhqOJQJ^JhJBXOJQJ^Jh@Ih=lrOJQJ^Jh=OJQJ^JDmn)*! !L!M!""$$$a$gd@I$^%_%%%'V)*e+,,,--Q0f2g2448696778999::$a$gd@I::::5;7;8;-?.?/?E?AuAvAwADDDDHHHHiIjI&K'KKLLsLtLLL0M1MMMMMMM[v[w[[[+\,\\\\\.]hJBXh-5OJQJ\^Jh-5OJQJ\^JhJBXh-OJQJ^Jh-OJQJ^JPPoSpSTTGVHVVYY8Y9YTYUY[[=[>[v[w[.]/]^^__ a a#a $7$8$H$a$gd-.]/]]]]]<^=^^^^^F_G_____2`3````` a a#a$axayaaabbbb*bubvbbb c!cxcycccc d d\d]dddeeXeYe|e}eeeeȸ߫鞸hTE5OJQJ\^JhJBXhTEOJQJ^JhJBXh-5OJQJ\^Jh55OJQJ\^Jh5OJQJ^Jh-OJQJ^JhJBXh-OJQJ^JhTEOJQJ^J>#a$acc|e}eeegggDgEgggiijjkkmmnnnnrr $7$8$H$a$gd-eeAfBfffffggggDgEggggg*B*CJOJQJ^JaJph)jh@Ih iCJOJQJU^JaJ h@Ih iCJOJQJ^JaJhUCJOJQJ^JaJ#h@Ih iCJOJQJ\^JaJ#h@Ih%CJOJQJ\^JaJ&hM,hc;5CJOJQJ\^JaJ&h@Ih=lr5CJOJQJ\^JaJ(VWѕҕ9:Зҗڗۗ^_ij WX`a>?@ٲٲٲٲ٤h@Ih iOJQJ^J h@IhUCJOJQJ^JaJh iCJOJQJ^JaJhUCJOJQJ^JaJ0h@Ih i0J>*B*CJOJQJ^JaJph h@Ih iCJOJQJ^JaJ)jh@Ih iCJOJQJU^JaJ/ښۚ@Ast͜ΜABJK:; z{ᾭ0h@Ih i0J>*B*CJOJQJ^JaJph)jh@Ih iCJOJQJU^JaJ h@Ih iCJOJQJ^JaJhUCJOJQJ^JaJ(h@Ih i0J>*B*OJQJ^Jphh@Ih iOJQJ^J!jh@Ih iOJQJU^J2ƛgۡߥة٩$ & F^a$gd@I$ & F^a$gd@I$ & F^a$gd@I$[$\$a$gd@I$ & F^a$gd@Iߠ%&./HIij£'(jkrs{|ǤȤ12wxîîîԠzzazzzazzz0h@Ih i0J>*B*CJOJQJ^JaJph)jh@Ih iCJOJQJU^JaJ h@Ih iCJOJQJ^JaJh/CJOJQJ^JaJ(h@Ih i0J>*B*OJQJ^Jph!jh@Ih iOJQJU^Jh@Ih iOJQJ^J h@IhUCJOJQJ^JaJh iCJOJQJ^JaJ&xޥߥqr¦æ78DELMة٩oooaaah/CJOJQJ^JaJ(h@Ih i0J>*B*OJQJ^Jph!jh@Ih iOJQJU^Jh@Ih iOJQJ^J h@Ih/CJOJQJ^JaJh iCJOJQJ^JaJ h@Ih iCJOJQJ^JaJ)jh@Ih iCJOJQJU^JaJ0h@Ih i0J>*B*CJOJQJ^JaJph:;sYZbc78ν}ooν}}}h/CJOJQJ^JaJ(h@Ih i0J>*B*OJQJ^Jph!jh@Ih iOJQJU^Jh@Ih/OJQJ^Jh@Ih iOJQJ^J h@Ih/CJOJQJ^JaJh iCJOJQJ^JaJ h@Ih iCJOJQJ^JaJ#h@Ih iCJOJQJ\^JaJ+\۳ܳdh$ & F^a$gd@I$ & F^a$gd@I$ & F^a$gd@I$[$\$a$gd@I$ & F^a$gd@I۳ܳصٵ23LM^_cd޼߼ӽͿͿͿ}#h@Ih iCJOJQJ\^JaJ h@Ih/CJOJQJ^JaJh iCJOJQJ^JaJ h@Ih iCJOJQJ^JaJh/CJOJQJ^JaJh@Ih iOJQJ^J!jh@Ih iOJQJU^J(h@Ih i0J>*B*OJQJ^Jph-h`aѿ\]34y $d]da$gdr0$ & F ^a$gd@I$ & F^a$gd@I$[$\$a$gd@I$ & F^a$gd@IӽԽ"#_`a\]jk234 kluv45ٲtٲccNcccNcc(h@Ih i0J>*B*OJQJ^Jph!jh@Ih iOJQJU^J#h@Ih iCJOJQJ\^JaJh/CJOJQJ^JaJh@Ih iOJQJ^J h@Ih/CJOJQJ^JaJh iCJOJQJ^JaJ0h@Ih i0J>*B*CJOJQJ^JaJph h@Ih iCJOJQJ^JaJ)jh@Ih iCJOJQJU^JaJgh®„„zm[MC6Ch@IhGZOJQJ^JhOJQJ^Jh@IhGZ5OJQJ^J#hh5CJOJQJ^JaJh@Ihr0OJQJ^JhsOJQJ^Jh/\hr0OJQJ^Jh/\hr05OJQJ\^Jhr05OJQJ\^J&hr0hr05CJOJQJ\^JaJhr0OJQJ^Jh@Ih iOJQJ^J(h@Ih i0J>*B*OJQJ^Jph!jh@Ih iOJQJU^J567KLijZ[{$-DM a$gd@I$a$gd@Ih56KLijZ[{|QRjk34rst"#ef@Abcfhi -CNh@IhGZ5OJQJ\^Jh@IhGZ6OJQJ]^Jh@IhOJQJ^JhGZOJQJ^JhOJQJ^JhsOJQJ^Jh@IhGZOJQJ^JB{|QRjk34rs"#=X{$-DM a$gd@I.ef@Abchi@A$-DM a$gd@I1>@ALS=>  PQbcCD< =   7 8 P Q S T m n y z       ٿ㨞 hM,hJBXCJOJQJ^JaJhJdOJQJ^JhGZOJQJ^Jh@Ih@IOJQJ^JhhGZOJQJ^Jh@IhOJQJ^JhOJQJ^Jh@IhGZOJQJ^Jh@IhGZ6OJQJ]^J7=>  PQbcCD< =   * C c  $-DM a$gd@I           8 9   -. $ & Fda$gdJBX$[$\$a$gdJBX$a$gdJBX$[$\$a$gdJBX$a$gd@I$-DM a$gd@I      8 9   +2`aĶxjj\K21jhJBXhJBXCJOJQJU^JaJmH sH hJBXheCJOJQJ^JaJhJBXCJOJQJ^JaJhCJOJQJ^JaJ hJBXhCJOJQJ^JaJh'jCJOJQJ^JaJh6:CJOJQJ^JaJ hJBXhJBXCJOJQJ^JaJhSRCJOJQJ^JaJhJBXhJBX5OJQJ\^JhM,hJBXOJQJ^J hM,hJBXCJOJQJ^JaJhM,CJOJQJ^JaJ),-.01 !45ijvijijҳ_ҳijO<$hJBXhJBX0JCJOJQJ^JaJh'j0JCJOJQJ^JaJ-hJBXhJBX0JB*CJOJQJ^JaJph hJBXhJBXOJQJ^JmH sH hJBXhJBXOJQJ^J hJBXh'jCJOJQJ^JaJhJBXCJOJQJ^JaJ hJBXhJBXCJOJQJ^JaJh'jCJOJQJ^JaJ1jhJBXhJBXCJOJQJU^JaJmH sH (hJBXhJBXCJOJQJ^JaJmH sH 01t# $ & Fha$gdJBX$ & FgP^Pa$gdJBX$ & FfP^Pa$gdJBX$ & FeP^Pa$gdJBX$[$\$a$gdJBX $ & Fda$gdJBX&E!#ACnpqŴŴyyjZh'j0JCJOJQJ^JaJhJBXhJBX0JOJQJ^J hJBXhJBXOJQJ^JmH sH $hJBXhJBX0JOJQJ^JmH sH heOJQJ^JhJBXhJBXOJQJ^J hJBXh'jCJOJQJ^JaJhJBXCJOJQJ^JaJheCJOJQJ^JaJh'jCJOJQJ^JaJ hJBXhJBXCJOJQJ^JaJ#Cpq\]+,<=`amn*!$[$\$a$gdJBX $ & Fha$gdJBXq\]+,<=_`amn*!+!"""""###$$ % % %%%'''ܰܢܔvhJBXhJBXOJQJ^J hJBXh'jCJOJQJ^JaJhJBXCJOJQJ^JaJhjSfCJOJQJ^JaJh'j0JCJOJQJ^JaJheCJOJQJ^JaJh'jCJOJQJ^JaJ hJBXhJBXCJOJQJ^JaJ$hJBXhJBX0JCJOJQJ^JaJ.*!+!""""##i###${$$$ % %%%'''2(3($a$gdJBX$ & FiP^Pa$gdJBX$[$\$a$gdJBX''2(3(J(.1.K/_/I1^183N355 6666667977779ƹƹwfwfXJfhAXCJOJQJ^JaJh/\CJOJQJ^JaJ h/\h"UCJOJQJ^JaJ h/\h6:CJOJQJ^JaJ h/\h"UCJOJQJ^JaJ h/\h?lCJOJQJ^JaJh-h-h-CJaJh-h-OJQJ^J h-h-CJOJQJ^JaJhJdOJQJ^J hJBXhJBXCJOJQJ^JaJhjSfCJOJQJ^JaJ3(J(K(((****++d,e,L-M-..1.2.J/K/_/`///\0 $a$gd-$a$gd-$[$\$a$gd-\0]0H1I1^1_112~227383N3O34444556677$[$\$a$gd/\$[$\$a$gd/\ $a$gd-$a$gd-99t9w999: :::::;;Y;];;;;<<<> >>>>>>>\?]?z?{?3A7A?AAAeAhAAAtCۺ۩ۺۺۓۺۺۺۺۺۋrrrhAXCJOJQJ^JaJh/\h"UCJaJh/\CJaJ*h/\h"U0J6CJOJQJ]^JaJ h/\hAXCJOJQJ^JaJ$h/\h"U0JCJOJQJ^JaJh/\CJOJQJ^JaJ h/\h"UCJOJQJ^JaJ&h/\h"U5CJOJQJ\^JaJ*799;;\?]?z?{?AAuCvC\F]FQLRLMMPPSSIWJWwW$a$gd/\ $a$gd/\$[$\$a$gd/\tCuCvC\F]FGG.IJJJJILNLOLQLRLLLLMMPP1Q7QЯЙsscUAA&h/\h"U5CJOJQJ\^JaJhjCJOJQJ^JaJhAX0JCJOJQJ^JaJ$h/\h"U0JCJOJQJ^JaJ$h/\h"UCJOJPJQJ^JaJ*h/\h"U0J6CJOJQJ]^JaJ$h/\h"U0JCJOJQJ^JaJh/\CJOJQJ^JaJ h/\h"UCJOJQJ^JaJ h/\hAXCJOJQJ^JaJh"UCJOJQJ^JaJ7Q9QXXXXXXXYY YYBYOYbYcYYYY ZZZZ^Z_ZĺĢĊĺĊĢĊĺĺĊĢĺĢĊĺĺĊĢukh"UOJQJ^J)h/\5OJQJ\^JfH`q /hVvh"U5OJQJ\^JfHq f/h/\h"U5OJQJ\^JfH`q h/\OJQJ^Jh/\h"UOJQJ^J$h/\h"U56OJQJ\]^J5h/\h"U56OJQJ\]^JfH`q )wWxWWW=X>X_Z`Z[[]^_&'($a$gdVv$a$gd/\_Z`ZZZZ [[[&['[[[[[[[[[[ \\c\d\q\\\]]"]ζ枉uZJh/\h"U6OJQJ]^J5h/\h"U56OJQJ\]^JfHq fh"UOJQJ^Jh/\OJQJ^J)h/\5OJQJ\^JfH`q /h/\h"U5OJQJ\^JfH`q /hVvh/\5OJQJ\^JfHq f/hVvh"U5OJQJ\^JfHq fh/\h"UOJQJ^Jh/\h/\OJQJ^J"]n]o]]]]]]]]]E^F^^^^^^^^^ _!_s_t_________ '4TUξξξuhVvh"UOJQJ^JU/h/\h"U5OJQJ\^JfH`q hVvOJQJ^J/hVvh"U5OJQJ\^JfHq fh/\h"U6OJQJ]^J5h/\h"U56OJQJ\]^JfHq fh/\OJQJ^Jh/\h"UOJQJ^J.Mantenimiento preventivo. Este tipo de mantenimiento es probablemente uno de los ms eficaces en funcin de los costos, ya que si se realiza de manera oportuna y adecuada, puede evitar serios problemas en el sistema. Un ejemplo de este mantenimiento es la correccin del problema del ao 2000. &'(h/\h/\h'jOJQJ^Jh/\h"UOJQJ^J21h:p=. A!"n#n$% t'Ddm   S A179A pesar de las mejoras en las metodologas, los proyectos software siguen siendo problemticos.b&+7cR%DDn%+7cRPNG  IHDRVp;WPLTE!!)!!!#!%"%$"#$"#!&"%$%%0' *!&(%-))+#,%**#5+)+(:,,.,<102 /0.33+7-241(<&B65748:7M> =?hh@Q`bMfl~}npBDphFRegGms|vIzxZ~~˚ȟaʤϧլfݮXl޴điÝơ̘_ˠvϣg¿|yŰ٬}˳݅⊻BbKGD cmPPJCmp0712Hs"oIDATx^|[}cCWF-8qtũ1Zǯ#yD8Mr-:mWVW>x}L}-,Wy i8x[-I9!@XH"6O$2±1)(DbKGYH56>lNElH"H$E?iw5MK@.WG\b,c1exy@mM!- 36Ws]֣> Ոx,v(8(plG(M > :2Pfp*d0n+%̲^'ԩSy@8u̅\NֹiZ&v2b 1GIq>qé% )G:>dp(b،Ddn:<9$7ɸ>s2.O*nw8uq+$3\U˴XC&1wa 1>xLj0el0.IO@&:217Қ?mAd(ݪhZh0 dJn/;H&hs,<¹!2(Bk QS<$yIfW0yPC\) pOjlѿ_Ks/,1JDh; «yW?xI8oՠh HA3oLhE#XwhP uFXwhP uFXwhP uFXwhP uF IDIX$LK4DK(B +a&g .^"N‹܊I)˲G}Ha )#P9d)mɺ(%oNJG%хF"YyDhȨmv+R} ~%n >bATHa:]*cW&BDPt[i/yF K3L]1@`O{ihR6 AL‹]$z">~;?{ UBm՚YS˷?~2o>KLN?g}VoQ㉛>2qO7~G}?z|v}Q]j_Z ؇& Hص{B*`k!JW}}{D B+ !"ߛ~2I@ML\"!Gnv4~#g:vQ @}{ϝ; F_<(Ǿ-9vnj[ qM-SDIYߴy3W6oޯZTC @(NN8&2GFs&[L{Ȯ*~pz}'.K[Sq2ZldQ<, J :7W;C[@~2rY3@^68vi^(tQ_1&ȑ];w,̞w<4QǤԐj۽ݻNHMK1)̰b )2NQ>{ΜQ1dZ 0uGI /]ѭ`/K% YGnU' )@]_b^k V[ IxYߺ7Z]ؖpսt5]lZNAJj-~Qt5Z'GG,eoêlG4 Z'!4Bh,3O9> !4Bh)5 /:Ycܠ2!T HS G>'u= j@HX{3 /:^ $zԣL hU?RUjO-JwRPj+}ՀOUV"?M+On]qQ_AԶcMmA 9j@_ j;7>bl*[Հ-EǛJW/w>Q%J4@!Q bgFȫ?r?B4˚ r { Sxi4zh>98P#b3:O'"߼M8:׎{/ 䁼鍐:ޖD48`2q8JNZ [QTȕ5 ~4#q:]{J>Wn>RN!<#L~jFpDžcׯ?,eu-N!4^)*qLq)kj#y3r~0'aV #v'U!S #A:gU(?;z:L|P/<<5 2|u6|Mnj̲pz{槈dK͖-[.I%fY3lt oF"(b^\1D_b,g{ 95 @PB bWr; @$@X<5Y,b1-AY$ }6';ld; ՀeccSgRȍvw~ɗ}m/ 1ŧz "⥜ծ%CՀRRTsKIUr(1{ Cǰx!A%zPeR !9>,.tKtKt+e^1ۖN{,β?T H\LQgE2@G'`F-괨W/HYݝ}$c / ^JX%S]aiԲ5WZ$um#TO$ >JVi<[8I5̳ꤤC7߲xn=ifi@ hеڶ|K-KlxZ۶gjԀo%yFNʞ\& a΢%B0oQfY0d2ٳ>iR&:B&&&.L]荆Fno<'D Q ot 9y]wp쮻z]N] _ ۇo:)!BHǪ'ܣ(3>g^"aQe #o5@pT䀈J9n: ug|d<<}$Hr[M \ j@qA hRPben~oTubz;$cSω@8R0[sU!~M'pʺX ^x!'`1@XG?9 jyo߾}?S= ^+)Pi!}Sܨwd]5;w|I8h#YC7_LG')oE8P2 {Ck7&%vd%1|Mrŷ"*.'i_^%d, ~f&GImY"o{;_Z `:$;#p[Bej@֡A~Wd?̭Wr'R@2zT_n9"Nyj@KM=<V6łe̲~/u뭷\CNYeALe2d͢\ qO WGU]|Qm Rb5  j@AɈ "mT2d6B~yj@W9Ej@$1 VbP 1(.~o+!ZTZDů ej@]Zڵ>k,+DTWW^ Z@ DՀumv4E*@޼T/eQ,EdxZ*@pU@$ZCh 5ZCh 5DBkHkUR5 Z'Ej@&DK_ / $7*?E؎ XObv2횚?ek$~ꋕSPDQuU!Y"5?g}V'%e r=J[>IS?X7Cj@j52%u}W]eՀ>"OBosnoOU5o7@cx?26o}q,>dKEȹ_ƛoFiD<}'LJo9"!4MUcGGș::~@&8>u=ܳM%|w~a`ݙرHEۻԛ@pP7WwjQ;Y\8HH5Sn[AƍOȐj|@Q[rQQ.uPе+W) RDJYtNۋx5dH !WaA R jU(r ԟB1e@r^ sV RH :@ 8YE@^~eL d<yG)me@Tj?Ee}ѦCԕS򶶶OZ^@D3^B1:I %W#j@Ej@eN)} q55{?[zi7"w <5˫,ߢF. Ԁή.\EDՀesKIibʲXm"T%"8E`nn\Cw*¿A J]c +~;)y{Gsvr7xR껔8\X~P~Cœz7w?$५r-HvN7:Dl523;Eao@%4HyuWN‘|\npBW II)|lԢ|%8I$@ u>#1/ruHWǿSDPݝ}$i}xX+ogNd>gY"<wI{6ηá3pxp@ xmotY! Q}=Ac=jgG~@FrkID֐l,uCHxqvb`Hx1HxQ&e'#`A'C‹OKMK _Ih+T;pNIx)}E姽$ޘ $Db@-u"i(Iå~c D1Rqi zZz'/Wlp9R -9ihhbQlaڥ18KCCc MvnA-a dE) DXCv /yK5ւ]v-vӍ'['*'uK<ufg?rQ0v_hs[Q'Sh_ u`/`r\Y%sR33^pIXE].x \pŽc+ J_QHƊ\pg\.K~;*RՋv] =/^EImv\ |e޸x1ۜFh(p=2A_wf*fE3Y 6LMij ] 9 rNڰg֖)n(rmf%*f!a ;pwhڔF6C-A]mm({J]ڀ2:.]Be{^TUztn o6.z9yޡu5^qSt}ruG ąY2\{ӳ.K \!|4,,e,%w^(؆ B8Xߜ u"c 5DBP6A#0N7Ġz=^lAŠ:/UkC355fw8!%!*Kbt `4"`|bP H_Z5$ j݀@r@FYV" [a2ɏs`Z#4 <4qr@us" 4cUb= %p6nYk@)/s@&lR@cPFd1w.֚y@IPt s@ V|tͪ/T3e.g 贬5skur4ׅ_7NW2:]tZR?V7 @~I2=&ŵ5]9PS܆u^iW}:E]ή9]Ձvd#H_p劺[GlQcx(CHBv<{@!YR55G@"6IM 81_ OP A( Dc#@46 Dc#fw2sbuh(F_k"QAμP $,n/j(WlGZRQbѰENiCfy0£hފF(f6ڹX")En EB 񃣇i D!k uc(azvqimj|c7ba)d{n9}48\?а1k@I \A;ڐ3ll` u Z9 "ː@t3k@C$blk k`AO[uB dl֜L,+tB @ϒpo AI( 9 %Q{OvzxX! y O4F.㨵dm)I;]}B2vL9 | ~h"GkMFD!9l'VdPPE!7 ‚9mo>qY;U^lPz y7FɿkIENDB`@@@ NormalCJ_HaJmH sH tH P@P JdTtulo 1dd@&[$\$5CJ0KH$\aJ0Z`Z -Ttulo 2$<@& 56CJOJQJ\]^JaJL@2L JdTtulo 3dd@&[$\$5CJ\aJNA@N Fuente de prrafo predeter.Ri@R  Tabla normal4 l4a ,k@, Sin lista:U@: i Hipervnculo >*phHJ^@J i Normal (Web)dd[$\$CJaJ>W@> =lrTexto en negrita5\,o!, "U systemitem(o1( "Uemphasis`g`A` "UMquina de escribir HTMLCJOJPJQJ^JaJoW ()PQ!"~ r 7 < m n )* LM^_V!"e#$$$%%Q(f*g*,,8.9.//0111227383.7v9w9<<@@iAjA&C'CCCDDEEEEFF8G9HHoKpKLLGNHNNQQ8Q9QTQUQSS=S>SvSwS.U/UVVWW Y Y#Y$Y[[|]}]]]___D_E___aabbcceeffffjjjjkkllnnoo@oAoMoNoqqrrttuuv vvvwwxxyy{{{{W|X|Y}}}}T~z~~Áށ߁т҂ʃ˃Մք׆؆ CD`ҍяҏ?@Ɠgۙߝء١\۫ܫdh`aѷ\]34ݺyνϽн567KLijZ[{|QRjk34rs"#=X{.ef@Abchi@A=> PQbcCD<=*Cc89  -. 0 1            t#Cpq\]+,<=`amn*+i{  2 3 J K   """"##d$e$L%M%&&1&2&J'K'_'`'''\(](H)I)^)_))*~**7+8+N+O+,,,,--..//1133\7]7z7{799u;v;\>]>BBCCFFIIMMMM'N(NNNPPRRSUEVmWnWqW0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0 0 0000 0 0 0000 0 0 000000 0 0 0000 0 0 0000 0 0 00000 0 0 0000 0 0 0000 0 0 0000@00@0@00000@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@00@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@000(00000000000000d 0d 0d 000000000000e 0f 0g 0000h 0h 0h 00000000000000000000000000000000i 0i 0i 0i 0i 0i 00000000000003 03 03 03 03 03 03 03 03 03 03 03 03 03 03 00&0&0&0&0K'0K'0K'0K'0K'0K'0K'0&0I)0I)0I)0I)0I)0I)0I)0&08+08+08+08+08+08+08+00-0-0-0-0-0-0-0-0-0-0]70]70]70]70]70]70]70]70]70]70]70]70]70]70]70]70]70]70]70]7@0]70]7@0]70]7@0]70]7@0]70]70]70]70]70]70]7P!m )L^V!"e#$$%f*,8./0173v9<@iA&CCbccee׆C@Ɠgۙء\۫haѷ\4ݺyν57KiZ{Qj3r"=X{.e@bh@= PbC<*Cc8 - 0       t#Cp\+<`m*i{ 2 ,,,-.13\7z79v;\>BCFIMM'NNPRSUEVmWnWqW@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0K0+0,d]K0+0K0+0K000@00@00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00@0(@0(K00XK00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00K00@0K009K009@0K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K009K00@0hK00K03x]K03K03 00K00(K00(K00(K00(K00(K00(K00(K00(K00(K00(K00(K00(K00(@0 (@0 (@0 (@0 (@0 (@0 (@0 (@0 (@0 (I0300:P.]eny؃׎Vxӽh q'9tC7Q_W_Z"]($:P#arƛh{ #*!3(\07wW((; S`̋֋^iV9^i W`ڒ@s͔AJ: zߘ%.Hi'jr{ǜ1wqž7DL:Yb7ح2L^޴ӵ"ku4)+  4 KLLoWXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXCXX8@0(  B S  ?AEN1519X-087-2-INTRO.SECURITYAEN1601-\7KqW3B LqWrc d Le lf >H g g h ̘i tj D&k O l m \e n o $+p 4q 5r (s 8H t 8H u :H v :H w ,x y  z T3 {  | 3 } D~    D O  l |        L L    ̖ :  :   D >H  D' 5\  6\   l:    t    4 TB , Ԇ  ,c 8\  9H  ?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqU90"$&_113bDDEuGGOHgHHH^IsJJMMRNtNNNNOtO>PQR)R^RRRSSURVVVW6WWWdXYZYYYAZ|ZZ[\%\B\{]]_u_p``bbnddeff g:gghjkkllmanopq(rar"sMsstttvwTww xz|Udֆ2;]x1 qW  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopq>r*urn:schemas-microsoft-com:office:smarttags PersonName /#La Administracinla Administracin Pblica. la Aurora.la Bodega CucumacaynLa BSA la Calidad la Comisin la Comisin.la Corte Supremala Dependenciala Dependencia.la Dependencia. Ella Dependencia. Nola Direccin Financierala Gerencia General la Gestinla Hoja La Ingenierala Institucinla Institucin.la Leyla Ley. la Mejorala Mejora Tecnolgicala Motherboardla Organizacin La Plataforma la Seccinla Supervisinla U.Ala UACI la Unidadla Unidad Organizativala Unidad Solicitante. ProductIDr"r"r"r" r"r" r" r" r"r" r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"!r"r"r"r"r"r"r"r"r" r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r" r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r"r" 04aefj~ o&s&N'R' ;;;;$;);*;4;b=f=??_CnCGGdHkHUU\\%`2`m`t`tt||/}7}:}I}kn #25 +.?BCFɕ̕(+x{36KNNQuxor\fNYgj-0γѳ>AŶȶNQPS4> # $ - . 4 @ F ?E   #./239:@+.####T)])m)v)G+L+`+e+0011*111t1w1|112 22233Y3]333446 666666688====????;ACADAMAAABB.C2C,F2F}GGGGGG7I:IMIPIUK]KqKtK|KKpLxLLLqW6B9B==.C2CpLxLqW333333<<CDEE9QTQ Y#Y}]]abu v{{Áށтʃքܫ]k[{Rj4Ms#=AbQb*c 0 Cq=aI)_)-.]7d7qWqW$/=T# L`Lff\;g2/!u, 4pk]O "%0WFs3a]h:ePjJÜ`NޡV!C->/҂~4 (6!7@ ;Tnm82;0ry=zGkcZ1G!/gGb&2I!RP.bkrV 6`V؊:qc r%"d~fpt&RqCw#&t${tzPovăz"{`:x4V.{܀|J^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`.^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`.^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(i`VJ%"d//|f!u, f# ԋ# RRRR;g2;g2(;g24;g2@;g2L:qcX:qcd:qcpkrV|krVkrVGGG!C-Č!C-Ќ~4܌~4/gG/gGm82; m82;m82;$m82;0<HT`k]O lk]O xk]O k]O k]O k]O k]O V.{V.{̍V.{TV.{`V.{l"{x"{"{"{"{#&t#&t#&t̒#&tؒry=ry=ry=ry=PovPov Pov,Pov8PovDPovPPov\PovhZ1GtZ1GZ1GZ1GZ1GZ1GZ1GZ1GȓZ1GԓFsFsFsFsFsFsFs(Fs@:eL:eX:ed&Rqp&Rq|&Rq(67@ ;${t3a]&2I      !"#$%&'()*+,-./0123456789$$OC~P&qGe.&qG&}&qG|/HmSddg&qGjs x] J &qG Uf &qG] &qG ) BB&qG>|\/HmSdd"D&qGI(#/HmSddR&qG&qGU\QXBBx-&qGK/HmSddc>&qG@X/HmSddg"$/HmSdd:)&qGlM-/HmSdd@.>|81j 1/HmSdd<2&qG{}_3&qGH05>|y>&qG3r?&qG:K@&qG'ZGB/HmSddCsVD>|<}D&qGH"F>oG81 &qGB&HH&qG;\nLyg _M/HmSddJM>|\QH05@0M-R&qG/HmS\S>| T&qGhU&qGl}VH"F OpZ&qGrZ>|7|Z'`j i^9[/HmSdd x]ud&qG"e&qG`6g/HmSddkeg&qG\!g&qGyg'`jCok&qGXqpk&qGqk&qGPs/HmSdd(hGu&qGx[(y&qGH|z/HmSdd!{/HmSdd+*%M,r0CH86:c;=6P=n=TEAXJBXGZ(\/\*aejSf i'j?l=lrVv6{/9yU"Uj54s@IJdSR7[Y-q2c]\@k74LALBGVoW@J@@UnknownGz Times New Roman5Symbol3& z ArialA Arial-BoldMTI& ??Arial Unicode MS?5 z Courier New;Wingdings"qu4"k4"kYn24dVV 2QHX)? i2c'Administracin de recursos informticosUserUser$                           ! " # Oh+'0  ( H T `lt|(Administracin de recursos informticosUserNormalUser15Microsoft Office Word@o5@>˧@N4"՜.+,D՜.+,T hp|  kV (Administracin de recursos informticos Ttulo  8@ _PID_HLINKSA9~Rhttp://www.ibiblio.org/pub/linux/docs/LuCaS/Manuales-LuCAS/GARL2/garl2/x1519.htmlFTN.AEN1601#FTN.AEN1601x*~1http://es.wikipedia.org/wiki/Principio_de_ParetoIp;xDhttp://www.monografias.com/trabajos15/llave-exito/llave-exito.shtmlISu>http://www.monografias.com/trabajos12/cntbtres/cntbtres.shtmlIq;r@http://www.monografias.com/trabajos14/nuevmicro/nuevmicro.shtmlIFPo5http://www.monografias.com/trabajos5/teap/teap.shtmlI|ul;http://www.monografias.com/trabajos5/psicoso/psicoso.shtmlactit;i8http://www.monografias.com/trabajos11/basda/basda.shtmlIf5http://www.monografias.com/Computacion/Programacion/Imc<http://www.monografias.com/Computacion/Sistemas_Operativos/IW`^http://www.monografias.com/trabajos15/medio-ambiente-venezuela/medio-ambiente-venezuela.shtmlIt;]8http://www.monografias.com/trabajos11/veref/veref.shtmlIv;Z8http://www.monografias.com/trabajos13/memor/memor.shtmlIq;WHhttp://www.monografias.com/trabajos14/consumoahorro/consumoahorro.shtmlI`/T<http://www.monografias.com/trabajos/seguinfo/seguinfo.shtmlIi|Q7http://www.monografias.com/trabajos6/napro/napro.shtmlI_N>http://www.monografias.com/trabajos13/discurso/discurso.shtmlIOZK5http://www.monografias.com/trabajos6/prod/prod.shtmlIq;H8http://www.monografias.com/trabajos14/mocom/mocom.shtmlIDQE5http://www.monografias.com/trabajos6/juti/juti.shtmlIJ^B5http://www.monografias.com/trabajos7/doin/doin.shtmlINK?5http://www.monografias.com/trabajos5/moti/moti.shtmldesap;<@http://www.monografias.com/trabajos15/liderazgo/liderazgo.shtmlIt;98http://www.monografias.com/trabajos11/fuper/fuper.shtmlIq;6Lhttp://www.monografias.com/trabajos14/dinamica-grupos/dinamica-grupos.shtmlIO3Fhttp://www.monografias.com/trabajos15/calidad-serv/calidad-serv.shtmlPLANT6f0:http://www.monografias.com/trabajos11/metods/metods.shtmlANALIT8e->http://www.monografias.com/trabajos12/romandos/romandos.shtmlPRUEBASV*Jhttp://www.monografias.com/trabajos15/la-estadistica/la-estadistica.shtmlIK'>http://www.monografias.com/trabajos11/ladocont/ladocont.shtmlIi}$7http://www.monografias.com/trabajos7/plane/plane.shtmlIq;!<http://www.monografias.com/trabajos14/control/control.shtmlICT9http://www.monografias.com/trabajos4/refrec/refrec.shtmlISF5http://www.monografias.com/trabajos6/meti/meti.shtmlIt;8http://www.monografias.com/trabajos11/veref/veref.shtmlIi}7http://www.monografias.com/trabajos7/herba/herba.shtmlIiyChttp://www.monografias.com/trabajos3/gerenylider/gerenylider.shtmlIi|7http://www.monografias.com/trabajos6/napro/napro.shtmlIXK 2http://www.monografias.com/Tecnologia/index.shtmlIN >http://www.monografias.com/trabajos12/elproduc/elproduc.shtmlI]>http://www.monografias.com/trabajos11/contrest/contrest.shtmlI^^http://www.monografias.com/trabajos15/mantenimiento-industrial/mantenimiento-industrial.shtmlIN>http://www.monografias.com/trabajos12/elproduc/elproduc.shtmlI  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~Root Entry FpData t'1Table^WordDocument4SummaryInformation(DocumentSummaryInformation8tCompObjr  F Documento Microsoft Office Word MSWordDocWord.Document.89q