ENFOQUE DE ADMINISTRACIÓN DE LA CALIDAD TOTAL

ENFOQUE DE ADMINISTRACIÓN DE LA CALIDAD TOTAL.

La administración de la calidad total (TQM, por sus siglas en inglés) es esencial a lo largo de todos los pasos del desarrollo de sistemas. Según Dean y Evans (1994), los principales elementos de la TQM sólo son significativos cuando se presentan en un contexto organizacional que favorece un esfuerzo integral por la calidad. Es en este contexto donde los elementos de enfoque en el cliente, planificación estratégica y liderazgo, mejora continúan, facultar al empleado y trabajo en equipo se unifican con el propósito de cambiar el comportamiento de los empleados y, en consecuencia, el curso de la organización.

SEISSEGMA.

La llegada de Seis Sigma ha cambiado el enfoque de la administración de la calidad. Cada analista de sistemas necesita estar consciente de Seis Sigma y aplicar algunos de los principios a sus proyectos de análisis de sistemas. Originalmente desarrollado por Motorola en la década de 1980, Seis Sigma es más que una metodología; es una cultura basada en la calidad. La meta de Seis Sigma es eliminar todos los defectos. Esto se aplica a cualquier producto, servicio o proceso. (Anexo Nº 1).

RESPONSABILIDAD DE LA ADMINISTRACIÓN DE LA CALIDAD TOTAL.

En términos prácticos, gran parte de la responsabilidad por la calidad de los sistemas de información recae en los usuarios de éstos y en los directivos. Para que la ADMINISTRACIÓN DE LA CALIDAD TOTAL (TQM) se vuelva una realidad en los proyectos de sistemas, deben darse dos condiciones. Primera, debe existir un apoyo organizacional incondicional por parte de los directivos, lo cual es distinto a simplemente respaldar el nuevo proyecto de los directivos.

Este apoyo significa establecer un con texto para que los directivos consideren seriamente cómo afecta su trabajo la calidad de los sistemas de información y la información misma. Es necesario que tanto el analista como la empresa se comprometan desde el principio con la calidad para lograr la meta de calidad. Este compromiso da como resultado un esfuerzo uniformemente controlado hacia la calidad durante todo el ciclo de vida del desarrollo de sistemas, y está en marcado contraste con tener que dedicar gran cantidad de esfuerzo para resolver problemas al final del proyecto.

DISEÑO Y DESARROLLO DE SISTEMAS.

Diseño ascendente: Este diseño se refiere a identificar los procesos que necesitan computarizarse conforme surgen, analizarlos como sistemas y codificar los procesos o comprar software empaquetado para resolver el problema inmediato. Cuando la programación interna se hace con un enfoque de ascendente, es difícil interconectar los subsistemas de manera que se desempeñen fácilmente como un sistema. Es muy costoso corregir las fallas de la interconexión y muchas de ellas no se descubren sino hasta que se completa la programación, cuando los analistas intentan reunir el sistema en la fecha límite señalada para la entrega. En esta situación, hay poco tiempo, presupuesto o paciencia del usuario para la depuración de interconexiones delicadas que se han ignorado.

Diseño descendente: El diseño descendente permite a los analistas de sistemas determinar primero los objetivos organizacionales globales, así como también determinar cómo se reúnen mejor en un sistema global. Después el analista divide dicho sistema en subsistemas y sus requerimientos.

DESARROLLO MODULAR.

Una vez que se toma el enfoque del diseño descendente, el enfoque modular es útil en la programación. Este enfoque implica dividir la programación en partes lógicas y manejables llamadas módulos.

El diseño de programa modular tiene tres ventajas principales. Primero, los módulos son más fáciles de escribir y de depurar porque prácticamente son independientes. Rastrear un error en un módulo es menos complicado, debido a que un problema en un módulo no debe causar problemas en otros.

Una segunda ventaja del diseño modular es que los módulos son más fáciles de mantener. Normalmente las modificaciones se limitarán a unos módulos y no seguirán en todo el programa.

Una tercera ventaja del diseño modular es que los módulos son más fáciles de entender, debido a que son subsistemas independientes. Por lo tanto, un lector puede adquirir una lista del código de un módulo y entender su función.

Algunos lineamientos para la programación modular incluyen lo siguiente:

1. Mantener cada módulo de un tamaño manejable, (incluir a la perfección una

sola función).

2. Poner particular atención a las interfaces críticas (los datos y variables de

control que se pasan a otros módulos).

3. Minimizar el número de módulos que el usuario debe modificar al hacer los

cambios.

4. Mantener las relaciones jerárquicas establecidas en las fases descendentes.

INGENIERÍA DE SOFTWARE Y DOCUMENTACIÓN.

La planeación y control son elementos fundamentales en todo sistema exitoso. En el desarrollo de software para el sistema, el analista de sistemas debe saber que la planeación tiene lugar en el diseño, incluso antes de que empiece la programación. Necesitamos técnicas que nos ayuden a establecer los objetivos del programa, de manera que nuestros programas estén completos.

PSEUDOCÓDIGO:

El pseudocódigo es similar al español estructurado porque no es un tipo particular de programar código, pero se puede usar como un paso intermedio para desarrollar el código de programa.

En la industria es común el uso del pseudocódigo, pero la falta de estandarización evitará que sea aceptado por todos. Debido a que el pseudocódigo está tan cerca del código de programa, naturalmente es favorecido por programadores y por consiguiente no es favorecido por analistas de negocios. El pseudocódigo con frecuencia se usa para representar la lógica de cada módulo en un diagrama de estructura.

MANUALES DE PROCEDIMIENTO:

Los manuales de procedimiento son documentos organizacionales comunes que la mayoría de las personas ha visto. Son el componente en Español de la documentación, aunque también podrían contener códigos de programa, diagramas de flujo, etc. Se pretende que los manuales comuniquen a aquellos que los usan.

Podrían contener comentarios de fondo, los pasos requeridos para lograr diferentes transacciones, instrucciones de cómo recuperarse de los problemas y qué hacer si algo no funciona (solucionar problemas). Actualmente muchos manuales están disponibles en línea, con capacidad de hipertexto que facilita el uso.

Las secciones importantes de un manual deben incluir una introducción, cómo usar el software, qué hacer si las cosas salen mal, una sección de referencia técnica, un índice e información de cómo contactar al fabricante. Los manuales en línea en los sitios Web también deben incluir información sobre descargar actualizaciones y una página de FAQ.

Los problemas con los manuales de procedimiento son que (1) están mal organizados, (2) es difícil encontrar la información necesaria en ellos, (3) el caso específico en cuestión no aparece en el manual y (4) el manual no está escrito en español. Más adelante, en la sección donde se habla de pruebas, discutimos la importancia de tener usuarios que "prueban" los manuales de sistemas y prototipos de los sitios Web antes de que se terminen.

EL MÉTODO DE FOLKLORE.

El FOLKLORE, es una técnica sistemática, basada en métodos tradicionales usados para recopilar el folklore sobre las personas y leyendas. Este enfoque para la documentación de sistemas requiere que el analista entreviste a los usuarios, investigue la documentación existente en los archivos y observe el procesamiento de información. El objetivo es recopilar la información correspondiente a una de cuatro categorías: costumbres, anécdotas, proverbios y formas artísticas. En Anexo Nº 2, sugiere cómo se relaciona cada categoría a la documentación de sistemas de información.

EL PROCESO DE PROBAR.

Aunque probar es tedioso, es una serie esencial de pasos que ayuda a asegurar la calidad del eventual sistema. Es mucho menos inquietante probar de antemano que tener un sistema probado deficientemente que falle después de la instalación. Las pruebas se realizan en subsistemas o módulos del programa conforme avance su desarrollo. Las pruebas se hacen en muchos niveles diferentes a varios intervalos. Antes de que el sistema se ponga en producción, todos los programas se deben verificar en el escritorio, verificar con datos de prueba y verificar para ver si los módulos trabajan entre sí como se planeó.

El sistema también se debe probar como un todo en funcionamiento. Incluso hay que probar las interfaces entre los subsistemas; la exactitud de salida; y la utilidad y entendimiento de la documentación y salida de sistemas. Como se muestra en el Anexo Nº 3, los programadores, analistas, operadores y usuarios cumplen un papel diferente en los varios aspectos a probar. Las pruebas de hardware normalmente se proporcionan como un servicio por los vendedores de equipo quienes ejecutarán sus propias pruebas en el equipo cuando se libere en el sitio.

Prueba de vínculos con datos de prueba: Cuando los programas pasan la verificación de escritorio y la verificación con datos de prueba, se deben pasar por las pruebas de vínculos, que también se conocen como prueba de cadena. Estas pruebas verifican si los programas que realmente son interdependientes trabajan juntos como se planeó.

Prueba completa de sistemas con datos de prueba: Cuando las pruebas de vinculación se concluyen satisfactoriamente, se debe probar el sistema como una entidad completa. En esta fase, los operadores y usuarios finales se involucran activamente en la prueba. Los datos de prueba, creados por el equipo de análisis de sistemas para el propósito expreso de probar los objetivos del sistema, se usan.

Como se puede esperar, hay varios factores a considerar cuando se prueban los sistemas con datos de prueba:

1. Examinar si los operadores tienen la documentación adecuada en los manuales

de procedimiento

(en papel o en línea) para asegurar un funcionamiento correcto y eficaz.

2. Verificar si los manuales de procedimiento son lo bastante claros como para

comunicar cómo se deben preparar los datos para la entrada.

3. Determinar si los flujos de trabajo necesarios para el sistema nuevo o

modificado realmente "fluyen".

4. Determinar si la salida es correcta y si los usuarios entienden que esta salida es

como se verá en su formulario final.

Prueba completa de sistemas con datos reales: Cuando las pruebas de sistemas con datos de prueba se realizan de manera satisfactoria, es bastante recomendable probar el nuevo sistema repetidas veces con lo que se conoce como datos reales, datos que se han procesado de manera exitosa con el sistema existente. Este paso permite una comparación precisa de la salida del nuevo sistema con la salida que sabe ha sido procesada correctamente, y también es una buena opción para probar cómo se manejarán los datos reales. Obviamente, este paso no es posible al crear salidas completamente nuevas (por ejemplo, salida de una transacción de comercio electrónico de un nuevo sitio Web corporativo). Al igual que con los datos de prueba, sólo se usan pequeñas cantidades de datos reales en este tipo de prueba de sistemas.

PRÁCTICAS DE MANTENIMIENTO.

Desde una perspectiva de sistemas, tiene sentido que detectar y corregir a tiempo los errores de diseño de software es menos costoso que permitir que permanezcan inadvertidos hasta que sea necesario el mantenimiento. Por lo regular el mantenimiento se realiza para mejorar el software existente en lugar de responder a una crisis o falla del sistema.

El mantenimiento también se hace para actualizar el software en respuesta a la organización cambiante. Este trabajo no es tan sustancial como mejorar el software, pero se debe hacer. El mantenimiento de emergencia y de adaptación representa menos de la mitad de todo el mantenimiento del sistema.

El analista de sistemas también necesita establecer un esquema de clasificación para permitir a usuarios designar la importancia percibida del mantenimiento sugerido o solicitado. Clasificar las solicitudes permite a programadores de mantenimiento entender cómo estiman los usuarios la importancia de sus solicitudes. Este punto de vista, junto con otros factores, se puede tener en cuenta al establecer el mantenimiento.

CÓMO AUDITAR.

Auditar se refiere a pedirle a un experto, que no esté involucrado en crear o usar un sistema, examinar la información para determinar su fiabilidad. Ya sea que la información se establezca o no para ser fiable, el descubrimiento en su fiabilidad se comunica a otros con el propósito de hacer la información del sistema más útil para ellos.

Generalmente hay dos tipos de auditores para los sistemas de información:

*- Los auditores externos se usan cuando el sistema de información procesa datos que influyen en las declaraciones financieras de una compañía. Los auditores externos auditan el sistema para asegurar la veracidad de las declaraciones financieras que se producen. También se podrían traer si ocurre algo fuera de lo normal que involucra a los empleados de la compañía, tal como la sospecha de un fraude electrónico o un desfalco.

*- Los auditores internos estudian los controles usados en el sistema de información para estar seguros que son adecuados y que están haciendo lo que deben hacer. También prueban la suficiencia de controles de seguridad. Aunque trabajan para la misma organización, los auditores internos no informan a las personas responsables del sistema que están auditando.

El trabajo de los auditores internos con frecuencia es más detallado que el de los auditores externos.

CAPACITACIÓN DE USUARIOS.

Los analistas de sistemas participan en un proceso educativo con los usuarios que se denomina capacitación. El usuario se ha involucrado en el ciclo de vida de desarrollo de sistemas por lo que ahora, el analista deba tener una valoración exacta de los usuarios que se deben capacitar. Como hemos visto, los centros de información tienen instructores propios.

En la implementación de proyectos grandes, el analista normalmente estará manejando la capacitación en lugar de estar involucrado personalmente en ella. Uno de los recursos más valiosos que el analista puede aportar en cualquier situación de capacitación es la habilidad de ver el sistema desde el punto de vista del usuario.

El analista nunca debe olvidar lo que es enfrentar un nuevo sistema. Esas recopilaciones pueden ayudar a analistas a identificarse con los usuarios y pueden facilitar su capacitación.

ESTRATEGIAS DE CAPACITACIÓN.

Los factores que determinan la estrategia de capacitación son las personas que serán capacitadas y quiénes las capacitarán. El analista tendrá que garantizar que cualquiera cuyo trabajo sea afectado por el nuevo sistema de información sea propiamente capacitado por el instructor correcto.

*- A quién capacitar Todas las personas que tendrán uso principal o secundario del sistema deben recibir capacitación. Esto incluye a todos, desde el personal de entrada de datos hasta aquellos que usarán la salida para tomar decisiones sin usar personalmente una computadora. La cantidad de capacitación que requiere un sistema depende de cuánto cambiará el trabajo de alguien debido al nuevo sistema.

Debe asegurarse de que los usuarios con diferentes niveles de habilidad e intereses de trabajo estén separados. Habrá problemas si incluye a principiantes en las mismas sesiones de capacitación que los expertos, debido a que los principiantes se pierden con rapidez y los expertos se aburren con los elementos básicos. En consecuencia, ambos grupos se pierden.

*- Personas que capacitan a los usuarios Para un proyecto grande, se podrían usar muchos instructores diferentes dependiendo de cuántos usuarios se deben capacitar y quiénes son.

Las posibles fuentes de capacitación incluyen lo siguiente:

1. Vendedores.

2. Analistas de sistemas.

3. Instructores externos.

4. Instructores internos.

5. Otros usuarios del sistema.

También es posible asignar a cualquiera de estos instructores para que capacite a un grupo pequeño de personas de cada área funcional que estará usando el nuevo sistema de información. A su vez, estas personas se pueden usar para capacitar al resto de los usuarios.

Este enfoque puede funcionar bien si los aprendices originales todavía tienen acceso a los materiales e instructores como recursos cuando ellos mismos proporcionen la capacitación. De lo contrario, esto podría acabar como una situación de prueba y error en lugar de una estructurada.

LINEAMIENTOS PARA LA CAPCITACIÓN.

El analista tiene cuatro lineamientos principales para establecer la capacitación. Éstos son:

*- Objetivos de la capacitación:

Los objetivos bien definidos son de gran ayuda permitiendo a los aprendices saber lo que se espera de ellos. Además, los objetivos permiten evaluación de capacitación cuando están completos.

*- Métodos de capacitación:

Cada usuario y operador necesitarán capacitación ligeramente diferente. Hasta cierto punto, sus trabajos determinan lo que necesitan saber y sus personalidades, experiencia y antecedentes determinan cómo aprenden mejor. Algunos usuarios aprenden mejor viendo, otros oyendo e incluso otros haciendo. Debido a que normalmente no es posible personalizar la capacitación para un individuo, una combinación de métodos es a menudo la mejor forma de proceder. Así, la mayoría de los usuarios se atrae mediante un método u otro.

Los métodos para aquellos que aprenden mejor viendo incluyen demostraciones de equipo y exposición para manuales de capacitación. Aquellos que aprenden mejor oyendo se beneficiarán de las conferencias sobre los procedimientos, discusiones y sesiones de preguntas y respuestas entre instructores y aprendices. Aquellos que aprenden mejor haciendo necesitan experiencia práctica con el nuevo equipo. Para trabajos como operador de computadora, la experiencia práctica es esencial, mientras que un gerente de control de calidad para una línea de producción sólo podría necesitar ver la salida, aprender a interpretarla y saber cuándo se espera que llegue.

*- Sitios de capacitación:

La capacitación se hace en muchas ubicaciones diferentes, algunas de las cuales son más favorables para aprender que otras. Los grandes vendedores de cómputo proporcionan ubicaciones remotas especiales en donde se mantiene equipo operable en forma gratuita. Sus instructores ofrecen experiencia práctica así como también seminarios en situaciones que permiten a los usuarios concentrarse en aprender el nuevo sistema.

Una de las desventajas de la capacitación remota es que los usuarios están fuera del contexto organizacional en el cual eventualmente se deben desempeñar.

La capacitación en las instalaciones de la organización a la cual pertenecen los usuarios también es posible con varios tipos diferentes de instructores. La ventaja es que los usuarios ven el equipo tal como estará cuando sea totalmente operacional.

*- Materiales de capacitación:

En la planeación de capacitación de usuarios, los analistas de sistemas deben comprender la importancia de los materiales de capacitación bien preparados. Estos materiales incluyen manuales de capacitación; casos de capacitación, en los cuales los usuarios se asignan para trabajar a través de un caso que incluye la mayoría de las interacciones normalmente encontradas con el sistema, y prototipos y muestras de salidas.

Los usuarios de sistemas grandes a veces se podrán capacitar en simulaciones detalladas basadas en Web o software que es idéntico a lo que se escribe o se compra.

CONVERSIÓN Y TIPOS:

Un tercer enfoque para la implementación es convertir físicamente el sistema de información viejo a uno nuevo o modificado. Hay muchas estrategias de conversión disponibles para analistas y también un enfoque de contingencia que tiene en cuenta diversas variables organizacionales para decidir qué estrategia de conversión usar.

En el Anexo Nº 4, se presentan las cinco estrategias para convertir del sistema viejo al nuevo y son como sigue:

*- Conversión Directa:

La conversión directa sólo puede tener éxito si la comprobación extensa se hace de antemano, y funciona mejor cuando se pueden tolerar algunos retrasos en el procesamiento. A veces, la conversión directa se hace en respuesta a un mandato gubernamental. Una ventaja de la conversión directa es que los usuarios no tienen ninguna posibilidad de usar el sistema viejo en lugar del nuevo. La adaptación es una necesidad.

*- Conversión paralela:

La conversión paralela se refiere a ejecutar al mismo tiempo el sistema viejo y el nuevo, en paralelo. Es el enfoque de conversión más frecuentemente usado, pero su popularidad podría estar bajando debido a que funciona mejor cuando un sistema computarizado reemplaza uno manual. Ambos sistemas se ejecutan simultáneamente por un periodo específico y la confiabilidad de los resultados se examina. Cuando se obtienen los mismos resultados todo el tiempo, el nuevo sistema se pone en uso y el viejo se detiene.

Una ventaja de ejecutar ambos sistemas en paralelo es la posibilidad de verificar los nuevos datos contra los viejos para percibir cualesquier errores en el procesamiento del nuevo sistema.

*- Conversión gradual:

La conversión gradual, o por fases, intenta combinar las mejores características de los dos planes previamente mencionados, sin incurrir en todos los riesgos. En este plan, el volumen de las transacciones manejado por el nuevo sistema aumenta gradualmente conforme el sistema se introduce por fases. Las ventajas de este enfoque incluyen permitir a usuarios que se involucren gradualmente con el sistema y la posibilidad de descubrir y recuperar errores sin desperdiciar mucho tiempo. Las desventajas de la conversión gradual incluyen tomar demasiado tiempo para colocar el nuevo sistema en el lugar y su impropiedad para la conversión de sistemas pequeños y sencillos.

*- Conversión de prototipo modular:

La conversión de prototipo modular usa la construcción de prototipos modulares y operacionales (como se discutió en el capítulo 6} para cambiar de los sistemas viejos a los nuevos de forma gradual. Conforme se modifique y acepte cada módulo, se pone en uso. Una ventaja es que cada módulo se prueba completamente antes de ser usado. Otra ventaja es que los usuarios se familiarizan con cada módulo conforme se vuelve operacional.

Con frecuencia no es posible la elaboración de prototipos, la cual automáticamente cancela este enfoque para muchas conversiones. Otra desventaja es que se debe poner especial atención a las interfaces para que los módulos que se construyen realmente trabajen como un sistema.

*- Conversión distribuida:

La conversión distribuida se refiere a una situación en que se contemplan muchas instalaciones del mismo sistema, como es el caso en actividades bancarias o franquicias tal como restaurantes o tiendas de ropa. Una conversión completa se hace (con cualquiera de los cuatro enfoques considerado previamente) en un sitio. Cuando esta conversión se completa exitosamente, se hacen otras conversiones para otros sitios.

Una ventaja de la conversión distribuida es que se pueden detectar y contener los problemas en lugar de infligir simultáneamente en todos los sitios. Una desventaja es que incluso cuando una conversión es exitosa, cada sitio tendrá sus propias peculiaridades para trabajar y se deben manejar como corresponde.

ASPECTOS DE SEGURIDAD PARA LOS SISTEMAS TRADICIONALES Y BASADOS EN LA WEB.

Es útil pensar en la seguridad de sistemas, datos e información en un continuo imaginario que va desde seguridad total hasta acceso abierto completamente. Aunque no hay tal cosa como un sistema totalmente seguro, las acciones de los analistas y usuarios pretenden mover los sistemas hacia el lado más seguro del espectro, disminuyendo la vulnerabilidad del sistema. Se debe observar que conforme más personas en la organización obtienen mayor poder de la computadora, obtienen acceso a la Web, o se acoplan a las intranets y extranets, la seguridad se vuelve incrementalmente difícil y compleja. A veces, las organizaciones contratarán a un consultor de seguridad para trabajar con el analista de sistemas cuando la seguridad es crucial para el funcionamiento exitoso.

La seguridad es responsabilidad de todos aquellos que están en contacto con el sistema, y sólo es tan buena como la conducta más indefinida o la política en la organización. La seguridad tiene tres aspectos interrelacionados: físico, lógico y conductual. Los tres deben trabajar juntos si la calidad de seguridad permanece alta.

SEGURIDAD FÍSICA.

La seguridad física se refiere a proteger el sitio donde se encuentra la computadora, su equipo y software a través de medios físicos. Puede incluir acceso controlado a las salas de cómputo por medio de signos legibles por la máquina o un registro de entrada y salida del sistema por un humano, usando cámaras de televisión de circuito cerrado para supervisar las áreas de la computadora y frecuentemente apoyando los datos y almacenando los respaldos en un área a prueba de fuego o a prueba de agua.

El analista debe tomar las decisiones acerca de la seguridad física cuando esté planeando las instalaciones de cómputo y la compra de equipo. Obviamente, la seguridad física puede ser mucho mejor si se planea con antelación a la instalación real y si las salas de cómputo se dotan de equipo de seguridad especial cuando se construyen en lugar de equiparse después de que están construidas.

SEGURIDAD LÓGICA.

La seguridad lógica se refiere a los controles lógicos en el software. Los controles lógicos son familiares para la mayoría de los usuarios como contraseñas o códigos de autorización de alguna clase. Cuando se usan, permiten al usuario entrar al sistema o a una parte particular de una base de datos con una contraseña correcta.

Una forma para que las redes reduzcan el riesgo de exposición al desafío de la seguridad del mundo exterior es construir un firewall o un sistema similar. Un firewall construye una muralla entre la red interna y la externa de una organización (tal como Internet). Se asume que la red interna es confiable y segura, mientras que Internet no lo es.

Se pretende que los firewalls impidan comunicación dentro o fuera de la red que no haya sido autorizada y que no se requiera. Un sistema firewall no es un remedio perfecto para la seguridad organizacional y de Internet; sin embargo, es una capa adicional de seguridad que ahora se acepta ampliamente. Todavía no hay ninguna forma totalmente integrada de solucionar los problemas de seguridad con las redes internas y externas, pero merecen la atención de analistas al diseñar cualquier sistema nuevo o mejorado.

SEGURIDAD CONDUCTUAL.

Las expectativas conductuales de una organización están implícitas en sus manuales de política e incluso en letreros anunciados en los carteles de anuncios. Sin embargo, la conducta que los miembros de la organización asimilan también es crítica para el éxito de los esfuerzos de seguridad. (Una razón por la que los firewalls no son totalmente a prueba de ataques es que muchos ataques a los sistemas de información vienen de adentro de la organización).

La seguridad puede empezar con la identificación de empleados que eventualmente tendrán acceso a las computadoras, datos e información, para asegurar que sus intereses son consistentes con los intereses de la organización y que entienden por completo la importancia de llevar a cabo los procedimientos de seguridad. Se deben escribir, distribuir y actualizar las políticas con respecto a la seguridad para que los empleados estén totalmente conscientes de las expectativas y responsabilidades. Es típico que el analista de sistemas primero tendrá contacto con los aspectos conductuales de la seguridad.

Algunas organizaciones han escrito reglas o políticas que prohíben a los empleados navegar en Web durante horas de trabajo o incluso prohíben totalmente la navegación de Web, si el equipo de la compañía está involucrado. Otras corporaciones usan software que bloquea el acceso a los sitios Web que se consideran inaceptables en el lugar de trabajo, tal como juegos, apuestas o sitios pornográficos.

CONSIDERACIONES DE SEGURIDAD PARA EL COMERCIO ELECTRONICO.

1. Software antivirus.

2. Productos de filtración de correo electrónico (como el Mail-Gear de Symantec) que proporciona servicios de filtrado de correo electrónico y archivos adjuntos basado en políticas y revisión para proteger a las compañías del correo electrónico entrante y saliente. La revisión del correo entrante protege contra ataques spam (correo electrónico no solicitado como los anuncios publicitarios) y la revisión del correo saliente protege contra la pérdida de información propia.

3. Productos de filtración de URL que proporcionan a los empleados acceso a Web por usuario, por grupos de usuarios, por computadoras, por tiempo o por el día de la semana.

4. Firewalls, gateways y redes privadas virtuales que impiden a los hackers acceder de forma clandestina a una red corporativa.

5. Productos de detección de intrusión (tal como Intruder Alert de Symantec) que continuamente supervisan el uso, proporcionan mensajes e informes y sugieren acciones a tomar.

6. Productos de administración de vulnerabilidad (tal como NetRecon y Symantec Expert) que evalúa los riesgos potenciales en un sistema y descubre e informa las vulnerabilidades. Algunos productos correlacionan las vulnerabilidades para que sea más fácil encontrar la raíz de los problemas. El riesgo no se puede eliminar, pero este software puede ayudar a manejarlo al equilibrar el riesgo de seguridad contra los costos de eliminarlos.

7. Tecnologías de seguridad tal como la capa de conexiones seguras (SSL) para la autenticación.

8. Tecnologías de encriptación tal como interpretación electrónica segura (SET).

9. Infraestructura de clave pública (PKI) y certificados digitales (obtenidos de una compañía tal como Verisign). El uso de certificados digitales asegura que el remitente informado del mensaje realmente es la compañía que envió el mensaje.

CONSIDERACIONES DE PRIVACIDAD PARA EL COMERCIO ELECTRÓNICO.

Cada compañía para la cual diseña una aplicación de comercio electrónico debe adoptar una política de privacidad. Aquí hay algunos lineamientos:

1. Inicie con una política corporativa de privacidad. Asegúrese que se despliega de forma prominente en el sitio Web para que todos los clientes puedan acceder la política siempre que completen una transacción.

2. Sólo pida la información que requiere la aplicación para completar la transacción en cuestión. Por ejemplo, ¿es necesario para la transacción preguntar la edad o género de una persona?

3. Haga opcional para los clientes completar la información personal en el sitio Web. A algunos clientes no les importa recibir mensajes concretos, pero siempre debe dar una oportunidad a los clientes de mantener la confidencialidad de sus datos personales al no responder.

4. Use fuentes que le permitan obtener información anónima sobre las clases de clientes. Por ejemplo, Engage es una compañía que ofrece al público tecnología de perfiles y soluciones de tecnología para administrar los anuncios, sus objetivos y su entrega. Esto se hace para mantener una base de datos dinámica de perfiles del cliente sin vincularlos a los individuos, por ello se respetan los derechos de privacidad de los clientes.

5. Sea ético. Evite el uso de trucos baratos que permitan a su cliente recopilar la información sobre el cliente de formas sospechosas o poco éticas. Los trucos tales como el raspado de pantalla (capturar remotamente lo que está en la pantalla de un cuente] y la toma de cookies de correo electrónico son violaciones claras de privacidad y también podrían ser ilegales.

Es esencial una política coordinada de seguridad y de privacidad. Es esencial establecer estas políticas y adherirse a ellas al implementar una aplicación de comercio electrónico.

BIBLIOGRAFIA.

*- Baskerville, R. L., "An Analytical Survey of Information Systems Security Design Methods: Implications for Information Systems Development", Computing Surveys, 1994.

*- Carlyle, R. E., "Squeezing the Middle", Datamation, vol. 32, núm. 10, 1986, pp. 26 - 28.

*- Derfler, F. J., Jr. y L. Freed, How Networks Work, Emeryville, CA: Ziff-Davis Press, 1993.

*- FitzGerald, J. y T. S. Eason, Fundamentáis ofData Communication, Nueva York: John Wiley, 1978.

*- Geier, J., "802.11 WEP: Concepts and Vulnerability", disponible en: <www.80211-planet com/tutorials/article.php/1368661>. Último acceso, 3 de junio de 2003.

*- Ginzberg, M. I, "Key Recurrent Issues in the MIS Implementation Process", MIS

Quarterly, vol. 5, núm. 2, 1981, pp. 47-59.

*- Gore, M. y J. Stubbe, Elements of Systems Analysis, 5a. ed., Nueva York: McGraw-Hill/ Irwin, 1993.

*- Jessup, L. M. y J. S. Valacich, Group Support Systems, Nueva York: Macmillan, 1993.

*- Kendall, K. E., "Evaluation of a Regional Blood Distribution Information System",

International Journal ofPhysical Distribution and Materiak Management, vol. 10,

núm. 7, 1980.

ANEXO

Introducción

La calidad ha sido durante mucho tiempo una preocupación para las empresas, como lo debe ser para los analistas de sistemas en el análisis y diseño de sistemas de información. Es demasiado arriesgado emprender todo el proceso de análisis y diseño sin usar un enfoque de aseguramiento de la calidad. Los tres enfoques para el aseguramiento de la calidad mediante ingeniería de software son: (1) garantizar el aseguramiento de la calidad total diseñando sistemas y software con un enfoque modular, descendente [de arriba a abajo); [2) documentar el software con las herramientas adecuadas, y [3) probar, mantener y auditar el software.

Dos propósitos guían el aseguramiento de la calidad. El primero es que el usuario del sistema de información es el factor individual más importante en establecer y evaluar su calidad. El segundo es que es mucho menos costoso corregir los problemas en sus fases iniciales que esperar hasta que un problema se manifieste a través de las quejas o crisis del usuario.

Ya hemos aprendido acerca de la enorme inversión de mano de obra y otros recursos empresariales que se requieren para desarrollar con éxito un sistema. El uso del aseguramiento de la calidad a lo largo del proceso es una forma de reducir los riesgos, ayuda a garantizar que el sistema resultante será lo que se necesita y desea, y mejorará notablemente algún aspecto del desempeño del negocio. Este capítulo proporciona al analista tres enfoques principales para la calidad.

Por otra parte también hay otros temas los cuales son de gran importancia cuando decimos la ingeniería e implementación de software ya que todo abarca un número de normas o reglas las cuales nos guiarán a la hora de diseñar un sistema da información.

Conclusión

Podemos decir que la ingeniería e implementación de software es importante a la hora de la creación de sistemas de información, ya que esto nos ayuda a desarrollarnos mejor en lo que vayamos hacer a la hora de crear o modificar un sistema de información. De allí parte la importancia de saber toda esas reglas que mencionamos anteriormente ya que así protegemos la información de nuestros sistemas de que puedan acceder a el personas o usuarios los cuales no les sea permitido, ya que muchos quisieran entrar para robar información y meter virus en nuestro equipo. Para todo esto cabe destacar que es importante este grupo de reglas para creación de sistemas.

República Bolivariana de Venezuela

Ministerio del poder popular para la Educación

U.E Fe y Alegría “Padre José María Velaz”

Prof.: Bricena Córdova

Mención: Informática

Integrantes:

Armando Díaz

Luisyani Cortesía

Ana María Urdaneta

5º “02”

Cumana/junio/2015

...