martes, 19 de mayo de 2009

Anexos

6.1. Carga de trabajo

Photobucket

6.2. Evaluación de 3 alternativas

Photobucket
Photobucket

Actualización (Update) y Mejora (Upgrade) del Software Principal

5.6.1.1. Determine en que parte del ciclo de vida se encuentra el software principal.

El desarrollo de software va unido a un ciclo de vida compuesto por una serie de etapas que comprenden todas las actividades, desde el momento en que surge la idea de crear un nuevo producto software, hasta aquel en que el producto deja definitivamente de ser utilizado por el último de sus usuarios.
Etapas en el ciclo.

Veamos, a grandes rasgos, una pequeña descripción de etapas con que podemos contar a lo largo del ciclo de vida del software; una vez delimitadas en cierta manera las etapas, habrá que ver la forma en que estas se afrontan (existen diversos modelos de ciclo de vida, y la elección de un cierto modelo para un determinado tipo de proyecto puede ser de vital importancia; el orden de las etapas es un factor importante, p.ej. tener una etapa de validación al final del proyecto, tal como sugiere el modelo en cascada o lineal, puede implicar serios problemas sobre la gestión de determinados proyectos; hay que tener en cuenta que retomar etapas previas es costoso, y cuanto más tarde se haga más costoso resultará, por tanto el hecho de contar con una etapa de validación tardía tiene su riesgo y, por su situación en el ciclo, un posible tiempo de reacción mínimo en caso de tener que retornar a fases previas):

Expresión de necesidades
Esta etapa tiene como objetivo la consecución de un primer documento en que queden reflejados los requerimientos y funcionalidades que ofrecerá al usuario del sistema a desarrollar (qué, y no cómo, se va a desarrollar).
Dado que normalmente se trata de necesidades del cliente para el que se creará la aplicación, el documento resultante suele tener como origen una serie de entrevistas cliente-proveedor situadas en el contexto de una relación comercial, siendo que debe ser comprendido por ambas partes (puede incluso tomarse como base para el propio acuerdo comercial).

Especificaciones
Ahora se trata de formalizar los requerimientos; el documento obtenido en la etapa anterior se tomará como punto de partida para esta fase. Su contenido es aún insuficiente y lleno de imprecisiones que será necesario completar y depurar.
Por medio de esta etapa se obtendrá un nuevo documento que definirá con más precisión el sistema requerido por el cliente (el empleo de los casos de uso, use cases, de Jacobson es una muy buena elección para llevar a cabo la especificación del sistema).

Lo más normal será que no resulte posible obtener una buena especificación del sistema a la primera; serán necesarias sucesivas versiones del documento en que irán quedando reflejada la evolución de las necesidades del cliente (por una parte no siempre sabe en los primeros contactos todo lo que quiere realmente, y por otra parte pueden surgir cambios externos que supongan requerimientos nuevos o modificaciones de los ya contemplados).

Análisis
Es necesario determinar qué elementos intervienen en el sistema a desarrollar, así como su estructura, relaciones, evolución en el tiempo, detalle de sus funcionalidades, … que van a dar una descripción clara de qué sistema vamos a construir, qué funcionalidades va a aportar y qué comportamiento va a tener. Para ello se enfocará el sistema desde tres puntos de vista relacionados pero diferentes:
Funcional.
Estático.
Dinámico.
Diseño

Tras la etapa anterior ya se tiene claro que debe hacer el sistema, ahora tenemos que determinar cómo va a hacerlo (¿cómo debe ser construido el sistema?; aquí se definirán en detalle entidades y relaciones de las bases de datos, se pasará de casos de uso esenciales a su definición como casos expandidos reales, se seleccionará el lenguaje más adecuado, el Sistema Gestor de Bases de Datos a utilizar en su caso, librerías, configuraciones hardware, redes, etc.).

Observación:
Aunque todo debe ser tratado a su tiempo, y sería muy deseable que las decisiones correspondientes en esta etapa fueran tomadas precisamente en esta etapa, muchas veces nos vamos a encontrar con unas decisiones previamente impuestas sobre lenguaje, plataforma, etc. Unas veces se dirán justificadas en simple política de empresa y por mantener “compatibilidad” en lo que respecta a los demás proyectos de la propia empresa, y en otras ocasiones por rumores de que tal o cual herramienta mejoraría la velocidad de desarrollo u otro aspecto de interés (en parte de los casos no serán rumores con fundamento o estudios previos realizados al efecto, sino más bien debidos a la propia publicidad como consejera).

Implementación
Llegado este punto se empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación y/o para un determinado sistema gestor de bases de datos.

Observación:
Lamentablemente en la actualidad, año 2.000, quedan bastantes empresas en las que, tras una reunión comercial en que tan solo se ha conseguido recabar una breve lista de requerimientos, a pesar de tener que enfrentarse a proyectos grandes-medios, se pasa directamente a la etapa de implementación; son proyectos guiados por el riesgo que supone adoptar un modelo de ciclo de vida de codificar-corregir (code and fix) donde se eliminan las fases de especificaciones, análisis y diseño con la consiguiente pérdida de control sobre la gestión del proyecto.

Pruebas
El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseño y/o programación. Es conveniente que sean planteadas al menos tanto a nivel de cada módulo (aislado del resto), como de integración del sistema (según sea la naturaleza del proyecto en cuestión se podrán tener en cuenta pruebas adicionales, p.ej. de rendimiento).

Validación
Esta etapa tiene como objetivo la verificación de que el sistema desarrollado cumple con los requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para esta fase también es interesante contar con los use cases, generados a través de las correspondientes fases previas, que servirán de guía para la verificación de que el sistema cumple con lo descrito por estos).
Mantenimiento y evolución

Finalmente la aplicación resultante se encuentra ya en fase de producción (en funcionamiento para el cliente, cumpliendo ya los objetivos para los que ha sido creada). A partir de este momento se entra en la etapa de mantenimiento, que supondrá ya pequeñas operaciones tanto de corrección como de mejora de la aplicación (p.ej. mejora del rendimiento), así como otras de mayor importancia, fruto de la propia evolución (p.ej. nuevas opciones para el usuario debidas a nuevas operaciones contempladas para el producto).

La mayoría de las veces en que se desarrolla una nueva aplicación, se piensa solamente en un ciclo de vida para su creación, olvidando la posibilidad de que esta deba sufrir modificaciones futuras (que tendrán que producirse con casi completa seguridad para la mayor parte de los casos).

5.6.1.2. ¿Con cuánta frecuencia se necesita llevarse a cabo la actualización del software principal?

Las Actualizaciones del sistema se darán cuando exista la necesidad de hacer algún cambio o corrección de estos siempre y cuando estos Sistemas son creados para una determina operación, en cambio sistemas creados para operaciones estándar con los sistemas operativos de los servidores de archivos y de las maquinas que acceden a esa información, antivirus, etc. deben de ser actualizados cada vez que la empresa responsable de estos sistemas y/o programas lancen nuevas actualizaciones.

5.6.1.3. ¿Con cuánta frecuencia se debe de dar mantenimiento?

El proceso de mejora y optimización del software debe ser de constante revisión como también corrección de los defectos.
El mantenimiento del software involucra varias técnicas específicas. Una técnica es el rebanamiento estático, la cual es usada para identificar todo el código de programa que puede modificar alguna variable. Es generalmente útil en la re fabricación del código del.

La fase de mantenimiento de software es una parte explícita del modelo en cascada del proceso de desarrollo de software el cual fue desarrollado durante el movimiento de programación estructurada en computadores. El otro gran modelo, el Desarrollo en espiral desarrollado durante el movimiento de ingeniería de software orientada a objeto no hace una mención explícita de la fase de mantenimiento. Sin embargo, esta actividad es notable, considerando el hecho de que dos tercios del costo del tiempo de vida de un sistema de software involucran mantenimiento.

En un ambiente formal de desarrollo de software, la organización o equipo de desarrollo tendrán algún mecanismo para documentar y rastrear defectos y deficiencias. El Software tan igual como la mayoría de otros productos, es típicamente lanzado con un conjunto conocido de defectos y deficiencias. El software es lanzado con esos defectos conocidos porque la organización de desarrollo en las utilidades y el valor del software en un determinado nivel de calidad compensan el impacto de los defectos y deficiencias conocidas.

Las deficiencias conocidas son normalmente documentadas en una carta de consideraciones operacionales o notas de lanzamiento (release notes) es así que los usuarios del software serán capaces de trabajar evitando las deficiencias conocidas y conocerán cuando el uso del software sería inadecuado para tareas específicas.
Con el lanzamiento del software (software release), otros, defectos y deficiencias no documentados serán descubiertas por los usuarios del software. Tan pronto como estos defectos sean reportados a la organización de desarrollo, serán ingresados en el sistema de rastreo de defectos.

Las personas involucradas en la fase de mantenimiento de software esperan trabajar en estos defectos conocidos, ubicarlos y preparar un nuevo lanzamiento del software, conocido como una lanzamiento de mantenimiento, el cual resolverá los temas pendientes.

Tipos de mantenimiento.
A continuación se señalan los tipos de mantenimientos existentes, definidos tal y como se especifican para la metodología de MÉTRICA:

Perfectivo:
son las acciones llevadas a cabo para mejorar la calidad interna de los sistemas en cualquiera de sus aspectos: reestructuración del código, definición más clara del sistema y optimización del rendimiento y eficiencia.
Evolutivo: son las incorporaciones, modificaciones y eliminaciones necesarias en un producto software para cubrir la expansión o cambio en las necesidades del usuario.
Adaptativo: son las modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios de configuración del hardware, software de base, gestores de base de datos, comunicaciones, etc.
Correctivo: son aquellos cambios precisos para corregir errores del producto software.
Cabe señalar que, de estos 4 tipos de mantenimiento, solamente el correctivo y el evolutivo entran dentro del ámbito de MÉTRICA versión 3, ya que los otros dos requieres actividades y perfiles distintos a los del proceso de desarrollo.


5.6.1.4. ¿Cómo afecta a otros departamentos dentro de la organización las actualizaciones o mantenimiento?

Las actualizaciones y mantenimiento de los sistemas deben de llevarse a cabo primero en un ambiente de pruebas adonde se tienen que hacer todas las pruebas a la actualización de tal forma de garantizar que la actualización no afectará los procesos que realizan o se llevan a cabo dentro de cada departamento de la organización.
Luego de realizar las respectivas pruebas estas actualizaciones se llevan a cabo en un momento que no afecten las operaciones diarias de los usuarios de la organización.

5.6.1.5. ¿Cómo se pueden minimizar estos efectos?
Teniendo la mayor compatibilidad del sistema se pueden minimizar tanto los tiempos de pruebas, como también minimizar el hecho de que existan demasiados errores por corregir debido a las nuevas actualizaciones. Como también tener una calendarización para llevar a cabo los respectivos mantenimientos y actualización del software.

5.6.1.6. ¿Qué puesto o persona será el responsable de ejecutar y monitorear las actualizaciones y mantenimientos?
El soporte técnico.

5.6.1.7. ¿Qué penalidades deben de ser impuestas si las actualizaciones o reparaciones no son ejecutadas en el horario previsto?

Dependiendo del nivel de importancia y consecuencia de no realizar la actualización, parche del sistema así será la penalidad impuesta al encargado de realizar la actividad programa. Por ej.
Sanciones
Consecuencias de los errores
Amonestación escrita AE
Atrasos A
Amonestación verbal AV
Pérdida física PF
Despido D
Pérdida humana PH
Llamada de atención LA
Pérdida monetaria PM
Ninguna N
5.6.1.8. ¿Se tiene un sistema de prevención para asegurarse que estas actividades sean completadas de manera efectiva?

Se debe de llevar una bitácora de las actividades realizadas, adonde se plasme el estatus actual de la actividad como también la finalización exitosa de dicha actividad.

5.6.1.9. ¿Quién es el responsable de comunicar y entrenar a los usuarios acerca de las actualizaciones y mantenimiento que los afectan?

Cuando las actualizaciones no son criticas y las pueden llevar a cabo los usuarios, estos serán notificados de que existen actualizaciones disponibles para sus sistemas, previo entrenamiento o capacitación por parte del departamento de soporte informático.

5.6.1.10. Desarrolle un horario para actualización y mantenimiento de equipo y software o sistemas de información (Entrada: Actualización y Mejora de Datos)

Día y hora para realizar Actualización Sistema Operativo Programa a Actualizar Descargas Hora de realización Realizado por:

Photobucket

Respaldo y Recuperación de Datos

5.5.1.1. ¿Cuáles son las necesidades de respaldo de la organización?
Todas las organizaciones dependen de la información, y si se llegase a dar una pérdida de datos implica también en perdida de dinero, es por ello que los respaldos son parte crucial de la organización.

5.5.1.2. ¿Cuáles son las expectativas administrativas de respaldo y recuperación?
- La principal expectativa es la integridad de los datos
- Que no haya fuga de información
- Que la recuperación de la información sea lo más rápida posible.
- Que los respaldos sean lo más actualizados posibles

5.5.1.3. ¿Qué personal se encarga del proceso de respaldo y recuperación?

Debe ser un encargado especifico para esa tarea, designado por el gerente de informática. O en tal caso el encargado de centro del cómputo.

5.5.1.4. ¿Cómo afectan las regulaciones de conformidad (Leyes sobre administración de información: Acta del Patriota, HIPAA, Sarbanes Oxley,) su proceso de respaldo y recuperación?

Primeramente tenemos que conocer un poco de lo que es cada uno de los documentos, por ejemplo: El Acta del Patriota:

La Ley Patriótica (Patriotic Act), denominada en inglés USA PATRIOT Act, es un acta del Congreso de los Estados Unidos que el presidente George W. Bush promulgó como ley el 26 de octubre de 2001. Su objetivo es restringir una serie de derechos constitucionales, a fin de ampliar el poder represivo del Estado sin la intervención del poder judicial, a fin de garantizar la seguridad nacional y combatir el terrorismo. La misma ha sido severamente criticada por organismos de derechos humanos debido a la restricción de las libertades y garantías constitucionales y ha sido considerada inconstitucional por varios tribunales.
Sanción y contenido
Su nombre oficial en inglés, “USA PATRIOT” es un acrónimo proveniente de la siguiente frase: Uniendo y Fortaleciendo América mediante la Provisión de Apropiadas Herramientas Requeridas para Interceptar y Obstruir el Terrorismo (Uniting and Strengthening América by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism). El acrónimo “USA PATRIOT” genera a su vez un slogan nacionalista equivalente a “ESTADOS UNIDOS PATRIÓTICO”.

El Acta fue aprobada cuarenta y cinco días después de los atentados del 11 de septiembre de 2001 y su objetivo fue ampliar sustancialmente los poderes represivos del Estado con el fin declarado de combatir el terrorismo, sin necesidad de orden judicial, tanto dentro como fuera de Estados Unidos, restringiendo una serie de derechos constitucionales. Entre sus previsiones, el Acta Patriótica incrementa las facultades de las agencias represivas para vigilar las comunicaciones telefónicas y de correo electrónico, así como los registros públicos y privados (médicos, financieros, libros solicitados en las bibliotecas, etc.); reduce las restricciones para acciones de inteligencia en otros países; aumenta el poder de la Secretaría del Tesoro para regular el mercado financiero; y concede poder discrecional a las autoridades policiales y migratorias para detener y deportar a inmigrantes, cuando se invoque que los mismos están sospechados de estar relacionados con el terrorismo. El Acta Patriótica también amplía la definición de terrorismo, con el fin de incluir actividades realizadas por ciudadanos estadounidenses y actos que antes no eran considerados como tal.

Después de conocer un poco lo que el Acta del Patriota, podemos exponer que esto no nos afecta en nuestro ambiente ya que nuestra organización no está ubicada geográficamente en Estados Unidos y esta ley afecta a toda organización que esté dentro del territorio Estadounidense

Ahora conozcamos un poco sobre el HIPAA

HIPAA es la ley federal de 1996 que se conoce como Ley de “Portabilidad” y Responsabilidad del Seguro Médico. La meta fundamental de la ley era facilitar a las personas el mantener un seguro médico, proteger la confidencialidad y la seguridad de la información del cuidado médico y ayudar a la industria del cuidado de la salud a controlar los costos administrativos.
HIPAA se divide en cinco títulos o secciones. Cada título trata un aspecto único de la reforma del seguro de salud. El Título I ya vigente es la movilidad (“portabilidad”). La movilidad permite a las personas llevar su seguro médico de un trabajo a otro para que no tengan un lapso en la cobertura. También restringe a los planes médicos de requerir condiciones preexistentes a personas que cambian un plan médico a otro.

El Titulo II se conoce como la Simplificación Administrativa y tendrá un impacto mayor para los proveedores. Se diseñó para:
• Combatir el fraude y abuso en el cuidado de la salud;
• Garantizar la seguridad y la privacidad de la información médica;
• Establecer estándares para la información y transacciones médicas y
• Reducir el costo del cuidado médico mediante la estandarización de la manera en que la industria comunica la información.
Los títulos restantes son:
• Título III – Disposiciones de Salud Relacionadas a Impuestos
• Título IV – Aplicación y Cumplimiento de los Requisitos de Planes Grupales de Salud
• Título V – Retenciones de Ingresos
¿Qué es la Simplificación Administrativa?

La Simplificación Administrativa es el establecimiento de un conjunto de estándares para recibir, transmitir y mantener información del cuidado médico y asegurar la privacidad y seguridad de la información identificable de una persona. HIPAA establece estándares para transacciones electrónicas del cuidado de la salud, conjuntos de códigos nacionales e identificación única para los proveedores, los planes de salud, los patronos y las personas.

Los requisitos de información electrónica de HIPAA tienen la intención de alentar a la industria del cuidado médico a mover el manejo y transmisión de la información del paciente de sistemas manuales a sistemas electrónicos para mejorar la seguridad, bajar los costos y bajar las tasas de error.

¿Cuáles son las Medidas Específicas de la Simplificación Administrativa?
• Conjuntos de Transacciones y Códigos – HIPAA ordena el desarrollo y uso de transacciones estandarizadas para el intercambio electrónico de información. Además requiere el uso de conjuntos de códigos nacionales estandarizados para identificar condiciones médicas, tratamientos, proveedores, personas, y procedimientos.

• Privacidad – Provee para la protección de información de salud individualmente identificable que se transmite o mantiene mediante cualquier forma o medio. Estas reglas se finalizaron y entraron y se ordenó su implementación para el 14 de abril de 2003. La regla de privacidad afecta las operaciones cotidianas de negocio de todas las organizaciones que proveen cuidado médico y que mantienen información personal de salud.

• Estándares de Seguridad – Los estándares de seguridad se diseñaron para proteger la información del cuidado médico mientras se almacena e intercambia. También incluyen medidas para corroborar la identidad de aquéllos que envían y reciben electrónicamente información de cuidado médico.

¿Qué Requiere la Regla de Privacidad?
A los proveedores se les requiere que:
1. Garanticen los derechos a la privacidad del paciente al:
o Entreguen a los pacientes explicaciones claras, por escrito de cómo el proveedor podría utilizar y revelar su información de salud;
o Aseguren que los pacientes puedan ver y obtener copias de sus expedientes y solicitar correcciones;
o Hagan un historial de revelaciones no rutinarias accesible a los pacientes;
o Obtengan el consentimiento del paciente antes de compartir su información para tratamiento, pago y actividades del cuidado médico;
o Obtengan la autorización del paciente para las revelaciones no rutinarias y la mayoría de los propósitos no relacionados al cuidado médico y
o Permitan a los pacientes solicitar restricciones en los usos y revelaciones de su información
2. Adopten procedimientos de privacidad por escrito que incluyan:
o Quién tiene acceso a la información protegida,
o Cómo se utilizará dentro de la agencia y
o Cuándo la información se revelará.
3. Se aseguren que los asociados del negocio protejan la privacidad de la información de salud.
4. Enseñen a los empleados los procedimientos de privacidad del proveedor.
5. Designen un oficial de privacidad que es responsable de asegurarse que los procedimientos de seguridad se cumplen.
Después de conocer un poco sobre esta ley, podemos resumir que esta ley trata sobre la privacidad de la información que los pacientes tienen de sus expedientes médicos, por tanto en el proceso de respaldo y recuperación de datos de nuestra organización no influye para nada.

Veamos lo que es Sarbanes Oxley

La Ley Sarbanes Oxley, cuyo título oficial en inglés es Sarbanes-Oxley Act of 2002, Pub. L. No. 107-204, 116 Stat. 745 (30 de julio de 2002), es una ley de Estados Unidos también conocida como el Acta de Reforma de la Contabilidad Pública de Empresas y de Protección al Inversionista. También es llamada SOx o SarbOx.
La Ley Sarbanes Oxley nace en Estados Unidos con el fin de monitorear a las empresas que cotizan en bolsa, evitando que las acciones de las mismas sean alteradas de manera dudosa, mientras que su valor es menor. Su finalidad es evitar fraudes y riesgo de bancarrota, protegiendo al inversor.
Esta ley, más allá del ámbito nacional, afecta a todas las empresas que cotizan en NYSEC (Bolsa de Valores De Nueva York), así como a sus filiales.
Introducción
La Ley Sarbanes-Oxley es una Ley federal de Estados Unidos que ha generado mucha controversia, ya que esta Ley va en respuesta a los escándalos financieros de algunas grandes corporaciones, entre los que se incluyen los casos que afectan a Enron, Tyco International, WorldCom y Peregrine Systems. Estos escándalos hicieron caer la confianza de la opinión pública en los sistemas de contabilidad y auditoría. La Ley toma el nombre del senador Paul Sarbanes (Demócrata) y el congresista Michael G. Oxley (Republicano). La Ley fue aprobada por amplia mayoría, tanto en el congreso como el senado. La legislación abarca y establece nuevos estándares para los consejos de administración y dirección y los mecanismos contables de todas las empresas que cotizan en bolsa en los Estados Unidos. Introduce responsabilidades penales para el consejo de administración y establece unos requerimientos por parte de la SEC (Securities and Exchanges Commission), es decir, la comisión reguladora del mercado de valores de Estados Unidos. Los partidarios de esta Ley afirman que la legislación era necesaria y útil, mientras los críticos creen que causara más daño económico del que previene.

La primera y más importante parte de la Ley establece un nueva agencia cuasi pública, “the Public Company Accounting Oversight Board”, es decir, una compañía reguladora encargada de revisar, regular, inspeccionar y disciplinar a las auditoras. La Ley también se refiere a la independencia de las auditoras, el gobierno corporativo y la transparencia financiera. Se considera uno de los cambios más significativos en la legislación empresarial, desde el “New Deal” de 1930.

Después de conocer un poco sobre esta ley podemos resumir que esta ley no afecta para nada nuestro proceso de respaldo y recuperación de datos.

5.5.1.5. Adicionalmente, ocúpese del proceso real de respaldar datos, como sigue:

5.5.1.6. ¿Cómo realizará usted el respaldo?

Los diferentes sistemas operativos tienen herramientas para realizar un backup, así que podemos hacer uso de tal herramienta para realizar nuestros respaldos.

5.5.1.7. ¿Cuándo tendrá lugar?

Por la importancia, la realizaría dos veces a la semana

5.5.1.8. ¿Cómo almacenaran los datos de respaldo y dónde?
- Los datos los almacenaremos de la forma siguiente:
- Una copia en un servidor fuera de la organización
- Una copia en un servidor dentro de la misma organización
- Dos copias en discos (medios físicos)

5.5.1.9. ¿Qué tipo de auditorías necesitarán para cumplir con las regulaciones de conformidad?

El Proceso de Auditoría es un registro mostrando a los detalles sobre quién ha tenido acceso a un sistema, operaciones realizadas y el tiempo de acceso. Un proceso de auditoría es el descubrimiento de interferencia componente esencial y recuperar datos perdidos.

El proceso de auditoría es una secuencia cronológica de archivos que contienen pruebas en cuanto a la función de sistema. Los procesos de auditoría son críticos para mantener la seguridad y remontar la causa de la pérdida de datos si alguno. Los productos de software de proceso de auditoría habilitan administraciones de red para supervisar el uso de recursos de red.

La pérdida de datos es causada debido a cualquier daño lógico o físico a los medios de almacenaje. Sin embargo las técnicas para ser aplicadas en los medios de almacenaje dependen de la causa de la pérdida de datos. Algunas técnicas de recuperación de datos son:
• Recuperación de datos lógica
En una situación de pérdida de datos cuando el disco duro es perfectamente la multa y el BIOS reconoce el disco duro, pero relata un error leído, la técnica de recuperación de datos lógica es muy provechosa. Aquí los archivos que son dañados o corrompidos por cualquier error de usuario o ataque de virus son reconstruidos más bien que reparar el disco duro.

• Fragmentación
Cuando la entrada GORDA es perdida durante el borrado de archivos casual, formateando o eliminación de partición que el bloque particular del disco duro se hace inaccesible. Algún software de recuperación de datos hace una tentativa de reconstruir los archivos sin una entrada GORDA. Esta técnica es muy eficiente si el tamaño de archivo es más pequeño que el tamaño de racimos. Pero son ineficaces en la recuperación los archivos más grandes.

• MFM (Microscopia de Fuerza Magnética)
El MFM es la última técnica que usa una punta aguda adjuntada a un voladizo flexible colocado cerca de la superficie del dispositivo dañado donde esto se relaciona con el campo magnético vago. Mientras la punta se mueve a través del dispositivo magnético, es evaluado para descubrir los datos perdidos. La técnica resulta cada pista que contiene una imagen de todo alguna vez escrito a ello, y finalmente recupera los datos perdidos.

Procedimientos de Contingencias

5.4.1.1. ¿Qué acontecimientos pueden provocar alarmas de un centro de cómputo?
-Ingreso de personal no autorizado.
-Incendios
-Cortos circuitos
-Terremotos


5.4.1.2. ¿Qué pasos deben tomarse para prevenir esas alarmas?
-Tener un extricto control de acceso de personal al centro de computo
-Extintor de inccendios.
-Equipo adicional para la reduccion de incendios.


5.4.1.3. ¿Cómo se verificarán cada una de esas alarmas?

Se verifican periódicamente dependiendo que tipo de alarmas se tengan….

5.4.1.4. ¿Cuáles son los procedimientos de solución si una alarma se convierte en un acontecimiento real?
1. Se determina qué tipo de alarma es (incidente).
2. Se analiza cual es la forma mas apropiada de solución
3. Se procede a dar solucion

5.4.1.5. ¿Qué puesto o persona será el responsable para resolver el acontecimiento?

Dependera del tipo de emergencia presentada.

5.4.1.6. ¿Cómo será contactado en el día o la noche está persona?
1. Por Teléfono, fax, E-mail, se busca la opción mas rápida…..

5.4.1.7. ¿Qué tareas de recuperación pueden ser iniciadas antes de que el acontecimiento sea resuelto?

5.4.1.8. ¿Qué puesto o persona declarará que el acontecimiento ha sido resuelto y que ya no necesita atención?
El adiministrador del centro de computo

Estimación de carga de trabajo

5.3.2.1. .Estimar la carga de trabajo de una de las operaciones de la empresa anexo 1

Photobucket

5.3.3. Evaluación del componente seleccionado
Este deberá de ser rápido y segura para tener mayor probecho del tiempo empleando este sistema, tener un prestigio mayor con nuestros sistemas que no dan problema alguno

5.3.3.1. Para evaluar alternativas deben seleccionar un componente ya sea: el servidor, el sistema operativo para servidor, otro tipo de software o sistema de información, etc. A excepción de un lote de computadoras que fue el ejemplo de la clase)
Microsoft SSQL server 2005

5.3.3.2. Investigar y obtener al menos 3 alternativas.
• Microsoft office Access 2003
• ORACLE
• Microsoft SQLite
• Microsoft SQL Express Edition

5.3.3.3. Llenar la tabla resumen (Anexo 2) con 3 alternativas por lo menos.

5.3.3.3.1. Determinar los criterios a evaluar,
• Rapidez: procesos por segundo que ejecuta
• Mantenimento:veces al mes que se tienen que hacer
• Costo: precio del programa
• Garantía: cuanto tiempo funcionara bien

5.3.3.3.3. A cada alternativa calificarla con un valor del 0 al 10, donde 10 es la nota más alta
Photobucket


5.3.3.3.4. Multiplicar la calificación de cada elemento por su valoración.
Photobucket

5.3.3.3.5. Realizar la sumatoria de todos los resultados de la alternativa
Photobucket

Inventario de computadoras

5.3.1. Levantar el inventario inicial del equipo informático


Photobucket

5.3.2. Establecer las operaciones de procesamiento de datos que se realizarán en el servidor o centro de cómputo de la empresa

Operaciones de procesamientos de datos:
• Creación de programas para super mercados
• Bases de datos
• Mantenimiento de programas varios
• Pprogramar seguridad a los software
• Encajar la información de la empresa con el programa

Entrada: Admón. Cambio

5.2.1.3. ¿Quién maneja esa adquisición y cómo se integra al centro de cómputo existente? (Entrada: Admón. Cambio)

•El analista de sistemas
•Es importante inventariar inmediatamente el equipo adquirido, procurando que la configuración haya sido hecha por el soporte técnico del fabricante o especialistas. Si el equipo es traído de otro país es muy difícil tener soporte técnico o reclamar por garantías si alguna parte viene dañada.

Entrada: Resumen Guía 4

5.2.1.1. ¿Quién es el encargado de tomar la decisión de compra de equipos tecnológicos dentro de su organización?
El analista de sistema con autorización del gerente de informática

5.2.1.2. ¿Qué ocurre si un departamento necesita espacio adicional de almacenamiento y debe comprarse un equipo nuevo? (proceso para adquirirlo)

Photobucket