Consideraciones especiales de seguridad para el comercio electrónico Se sabe bien que los intrusos pueden violar la integridad de cualquier sistema de cómputo. Como analista, necesita tomar diversas precauciones para proteger la red de cómputo de las amenazas de seguridad en Web internas y externas. Varias acciones y productos le pueden ayudar: 1. Software antivirus. 2. Productos de filtración de correo electrónico que proporcionan servicios de exploración y filtrado de correo electrónico y archivos adjuntos, basado en políticas para proteger a las compañías del correo electrónico entrante y saliente. La exploración del correo entrante protege contra ataques de spam (correo electrónico no solicitado, como los anuncios publicitarios) y la exploración del correo saliente protege contra la pérdida de información propietaria. 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 impidan a los hackers acceder a una red corporativa. 5. Productos de detección de intrusión y antiphishing que continuamente supervisan el uso, proporcionan mensajes e informes y sugieren acciones a tomar. 6. Productos de administración de vulnerabilidad que evalúan los riesgos potenciales en un sistema y descubren e informan las vulnerabilidades. Algunos productos correlacionan las vulnerabilidades para que sea más fácil encontrar la raíz de la fuga de seguridad. 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 cifrado tales como la transacció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 sea la compañía que envió el mensaje. Consideraciones de privacidad para el comercio electrónico El otro aspecto de la seguridad es la privacidad. Para hacer su sitio Web más seguro, debe pedir a los usuarios o clientes que renuncien a cierta privacidad. Como diseñador de un sitio Web, reconocerá que la empresa para la que usted diseña ejerce mucho poder sobre los datos que proporcionan sus clientes. Los mismos principios de conducta ética y legal se aplican al diseño de sitios Web como al diseño de cualquier aplicación tradicional que acepta datos personales de clientes. Sin embargo, la Web permite recopilar datos con más rapidez y diferentes (como los hábitos de navegación del cliente). En general, la tecnología de la información hace posible almacenar más datos en los almacenes de datos, procesarlos y distribuirlos más ampliamente. Cada compañía para la cual usted diseña una aplicación de comercio electrónico debe adoptar una política de privacidad. He aquí algunos lineamientos:

1. Inicie con una política corporativa de privacidad. Asegúrese que se despliegue de forma prominente en el sitio Web para que todos los clientes puedan acceder la política siempre que completen una transacción. 2. Solicite sólo la información que la aplicación requiera 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. Hay compañías que ofrecen 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 de clientes sin vincularlos a los individuos, respetando así 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 cliente) y la toma de cookies de correo electrónico son violaciones claras de privacidad; además 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. Planeación de recuperación de desastres Sin importar con qué diligencia trabajen usted y sus colegas para asegurar la seguridad y estabilidad de los sistemas, todos los empleados y los sistemas son inevitablemente vulnerables a cierto tipo de desastre natural o provocado por los humanos, que amenaza tanto la seguridad como el mismo funcionamiento de la empresa. Algunos desastres son bastante comunes, como los cortes de energía, y podemos evaluar la probabilidad de que ocurran algunos desastres, como un huracán o terremoto. Sin embargo, muchos otros son inesperados en cuanto a su ocurrencia o severidad, tal vez incluso hasta provoquen la pérdida de vidas humanas, creando caos para las personas y la organización en sí. Los campos relacionados con el grado de preparación y la recuperación contra los desastres son interdependientes y se basan uno en el otro. El grado de preparación contra desastres incluye lo que una empresa debería hacer si encuentra una crisis. El campo de la recuperación contra desastres se enfoca en la forma en que una empresa puede continuar como secuela de un desastre y cómo puede restaurar los sistemas esenciales en la infraestructura de TI. Esta sección se enfoca en la recuperación de desastres y su relación con los sistemas de información.

El proceso tradicional de recuperación de desastres consiste en la planeación, el recorrido, los ejercicios de práctica y la recuperación del desastre. Al sufrir un desastre, la empresa se arriesga a perder personas, dinero, reputación y sus propios bienes, así como los de sus clientes. Es importante hacer lo correcto para minimizar las pérdidas potenciales. Los analistas deben determinar cuál es el nivel de planeación contra desastres de la organización y qué tan bien articulado está el rol de sistemas de información en sus planes de respuesta y recuperación en caso de desastres. Las preguntas clave que se deben hacer los analistas lo antes posible son: 1) si los empleados saben a dónde ir y 2) qué hacer en caso de un desastre. La respuesta a estas preguntas lo guiará a través del proceso de planeación. La sabiduría convencional provee siete elementos a considerar durante y después de un desastre. Como veremos, muchos de estos elementos involucran a los sistemas de información y se relacionan de manera específica con la planeación que usted debe proveer como analista de sistemas. 1. Identificar los equipos responsables para administrar una crisis. 2. Eliminar puntos individuales de fallas. 3. Determinar las tecnologías de duplicación de datos que coincidan con la agenda de la organización para poner los sistemas en funcionamiento. 4. Crear planes de reubicación y transportación detallados. 5. Establecer varios canales de comunicación entre los empleados y consultores que están en el sitio, como los equipos de analistas. 6. Proveer soluciones de recuperación que incluyan una ubicación remota. 7. Asegurar el bienestar físico y psicológico de los empleados y otros que puedan estar físicamente presentes en el sitio de trabajo cuando ocurra un desastre. El plan de preparación para desastres debe identificar a los responsables de realizar varias decisiones fundamentales en caso de un desastre. Hay que decidir si van a continuar o no las operaciones comerciales; cómo brindar soporte para las comunicaciones (tanto de computadora como de voz); a dónde se enviarán las personas si las instalaciones de la empresa son inhabitables; a dónde irá el personal en caso de una emergencia; ocuparse de las necesidades personales y psicológicas de las personas presentes en la empresa y los que podrían trabajar en forma virtual; y restaurar los entornos principales de cómputo y laborales. La redundancia de los datos provee la clave para eliminar puntos individuales de fallas para los servidores que ejecutan aplicaciones Web. Como analista, usted puede ser especialmente útil para establecer este tipo de respaldo y redundancia. Algunas empresas están migrando a las redes de área de almacenamiento (SAN) para evitar parte de la inestabilidad asociada con los respaldos físicos en cintas magnéticas y su almacenamiento. La duplicación remota sincrónica (también conocida como discos en espejo, o data mirroring) también está ganando popularidad. Pero si las empresas están a más de 100 millas de distancia del sitio, el proceso de discos en espejo se puede ver afectado.

La duplicación remota asíncrona envía datos a la ubicación de almacenamiento secundaria en intervalos de tiempo designados. Hay opciones en línea para pequeñas empresas también. La organización debe desarrollar y distribuir a todos un memorándum de una página que contenga las rutas de evacuación y los puntos de reunión de los empleados. Las tres opciones comunes son enviar a los empleados a sus casas, hacer que permanezcan dentro de las instalaciones o reubicarlos a una instalación de recuperación preparada para continuar operando. Hay que tener en cuenta toda la gama de opciones de transportación a la hora de desarrollar este memo. Los miembros de la organización y del equipo de análisis de sistemas deben ser capaces de comunicarse en caso de que se interrumpa el sistema ordinario de correo electrónico. Si no hay correo electrónico disponible para transmitir un mensaje de emergencia, una página Web con información de emergencia o una línea telefónica pueden servir para tal fin como alternativas viables. Hace poco, varias empresas de software empezaron a ofrecer una suite de herramientas de software que permiten la comunicación ad hoc mediante agencias de respuesta de emergencia que les permiten establecer con rapidez herramientas de VoIP, conectividad Web y Wi-Fi. La disponibilidad cada vez más amplia y los precios más bajos sin duda llevarán en el futuro estas importantes herramientas de comunicación a otros tipos de organizaciones. Para proteger mejor los sistemas de respaldo de la organización y asegurar el flujo continuo de las transacciones bancarias en caso de un desastre, las nuevas regulaciones en los Estados Unidos estipulan que las ubicaciones remotas de los bancos deben estar por lo menos a 100 millas de distancia del sitio original. Como los archivos y respaldos en papel también representan un gran problema y son muy vulnerables a los desastres naturales y humanos, es imprescindible que las organizaciones creen un plan que les ayude a migrar hacia un proyecto de documentación digital con el fin de convertir todos sus documentos en papel a formatos electrónicos, dentro de un plazo de entre tres y cinco años después de su creación (Stephens, 2003). El soporte para los humanos que trabajan en una organización que experimenta un desastre es algo primordial. Debe haber suficiente agua potable a la que se tengan fácil acceso, en especial si los empleados no pueden salir del sitio durante varios días debido a las condiciones del clima exterior o derrumbamientos parciales de edificios. Aunque la comida es importante, el agua lo es más. También se debe proporcionar a los empleados un kit de seguridad que contenga agua, una mascarilla antipolvo, una linterna, barras luminosas y un silbato. Una forma de averiguar qué debe contener un kit de provisiones contra desastres para el espacio de trabajo individual es ir al sitio Web de la Cruz Roja Americana (www.redcross.org), donde se proveen los detalles para apoyar a las personas en caso de desastres y hacerse cargo de ellas.

Business Process Model and Notation

después de los mismos.

Business Process Model and Notation

Ejemplo de diagrama de proceso de negocio.

Business Process Model and Notation (BPMN), en español Modelo y Notación de Procesos de Negocio), es una notación gráfica estandarizada que permite el modelado de procesos de negocio, en un formato de flujo de trabajo (workflow). BPMN fue inicialmente desarrollada por la organización Business Process Management Initiative (BPMI), y es actualmente mantenida por el Object Management Group (OMG), después de la fusión de las dos organizaciones en el año 2005. Su versión actual, es la 2.0.2.

El principal objetivo de BPMN es proporcionar una notación estándar que sea fácilmente legible y entendible por parte de todos los involucrados e interesados del negocio (stakeholders). Entre estos interesados están los analistas de negocio (quienes definen y redefinen los procesos), los desarrolladores técnicos (responsables de implementar los procesos) y los gerentes y administradores del negocio (quienes monitorizan y gestionan los procesos). En síntesis, BPMN tiene la finalidad de servir como lenguaje común para cerrar la brecha de comunicación que frecuentemente se presenta entre el diseño de los procesos de negocio y su implementación.

La gestión por procesos se confirma como uno de los mejores sistemas de organización empresarial para conseguir índices de calidad, productividad y excelencia. 1 . En un contexto empresarial y económico tan complejo, globalizado y competitivo como el actual, la gestión de procesos se ha convertido en una necesidad para las empresas, no para tener éxito, sino incluso también para subsistir.

Actualmente hay una amplia variedad de lenguajes, herramientas y metodologías para el modelado de procesos de negocio. La adopción cada vez mayor de la notación BPMN como estándar, ayudará a unificar la expresión de conceptos básicos de procesos de negocio (por ejemplo: procesos públicos y privados, orquestación, coreografía, etcétera) así como conceptos avanzados de modelado (por ejemplo: manejo de excepciones, compensación de transacciones, entre otros).

Ámbito de la BPMN[editar]

BPMN está planeada para dar soporte únicamente a aquellos procesos que sean aplicables a

procesos de negocios. Esto significa que cualquier otro tipo de modelado realizado por una

organización con fines distintos a los del negocio no estará en el ámbito de BPMN. Por ejemplo,

los siguientes tipo de modelado no estarían en el ámbito de BPMN:

Estructuras organizativas;

Descomposición funcional;

Modelos de datos.

Adicionalmente, a pesar de que BPMN muestra el flujo de datos (mensajes) y la asociación de

artefactos de datos con las actividades, no es de ningún modo un diagrama de flujo de datos.

Elementos[editar]

El modelado en BPMN se realiza mediante diagramas muy simples con un conjunto muy

pequeño de elementos gráficos. Con esto se busca que para los usuarios del negocio y los

desarrolladores técnicos sea fácil entender el flujo y el proceso. Las cuatro categorías básicas

de elementos son:

Objetos de Flujo: Eventos, Actividades, Rombos de control de flujo (gateways);

Objetos de Conexión: Flujo de Secuencia, Flujo de Mensaje, Asociación;

Carriles de nado (swimlanes): Piscina, Carril;

Artefactos: Objetos de Datos, Grupo, Anotación.

Estas cuatro categorías de elementos nos dan la oportunidad de realizar un diagrama simple

de procesos de negocio (en inglés Business Process Diagram, BPD). En un BPD se permite

definir un tipo personalizado de objeto de flujo o un artefacto, si con ello se hace el diagrama

más comprensible.

“Objetos de Flujo”[editar]

Eventos.

Actividades.

Compuertas (Control de Flujo).

Conexiones.

Objetos de Flujo son los elementos principales descritos dentro de BPMN y consta de tres

elementos principales: Eventos, Actividades y Compuertas (Control de Flujo).

Eventos

Están representados gráficamente por un círculo y describen algo que sucede (a

diferencia de las Actividades que son algo que se hace). Los eventos también pueden

ser clasificados como “Capturado” o “Lanzado”.

Evento Inicial

Actúa como un disparador de un proceso. Se representa gráficamente por un círculo

de línea delgada relleno de color verde. Este evento permite “Capturar”.

Evento Final

Indica el final de un proceso. Está representado gráficamente por un círculo de línea

gruesa relleno del color rojo. Este evento permite “Lanzar”.

Evento Intermedio

Indica que algo sucede entre el evento inicial y el evento final. Está representado

gráficamente por un círculo de doble línea simple relleno de color naranja. Este evento

puede “Capturar” o “Lanzar”.

Actividades

Se representan por un rectángulo de vértices redondeados y describe el tipo de trabajo

que será realizado.

Tarea

Una tarea representa una sola unidad de trabajo que no es o no se puede dividir a un

mayor nivel de detalle de procesos de negocio sin diagramación de los pasos de un

procedimiento.

Subproceso

Se utiliza para ocultar o mostrar otros niveles de detalle de procesos de negocio.

Cuando se minimiza un subproceso, se indica con un signo más contra de la línea

inferior del rectángulo, cuando se expande el rectángulo redondeado permite mostrar

todos los objetos de flujo, los objetos de conexión, y artefactos. Tiene, de forma

autocontenida, sus propios eventos de inicio y fin; y los flujos de proceso del proceso

padre no deben cruzar la frontera.

Transacción

Es una forma de subproceso en la cual todas las actividades contenidas deben ser

tratadas como un todo. Las transacciones se diferencian de los subprocesos

expandidos por estar rodeando por un borde de doble línea.

Compuertas (Control de Flujo)

Se representan por una figura de diamante y determinan si se bifurcan o se combinan

las rutas dependiendo de las condiciones expresadas.

“Objetos de Conexión”[editar]

Los objetos de conexión permitirán conectar cada uno de los objetos

de flujo. Hay tres tipos: Secuencias, Mensajes y Asociaciones.

Flujo de Secuencia

Está representado por línea simple continua y flechada; y muestra el orden en que las

actividades se llevarán a cabo. El flujo de secuencia puede tener un símbolo al inicio,

un pequeño diamante indica uno de un número de flujos condicionales desde una

actividad, mientras que una barra diagonal indica el flujo por defecto desde una

decisión o actividad con flujos condicionales.

Flujo de Mensaje

Está representado por una línea discontinua con un círculo no relleno al inicio y una

punta de flecha no rellena al final. Esto nos dice, que el flujo de mensaje atraviesa la

frontera organizativa (por ejemplo, entre piscinas). Un flujo de mensaje no puede ser

utilizado para conectar actividades o eventos dentro de la misma piscina.

Asociaciones

Se representan por una línea de puntos. Se suele usar para conectar artefactos o un

texto a un objeto de flujo y puede indicar muchas direccionabilidades usando una

punta de flecha no rellena (hacia el artefacto para representar a un resultado, desde el

artefacto para representar una entrada, y los dos para indicar que se lee y se

actualiza). La “no direccionabilidad” podría usarse con el artefacto o un texto está

asociado con una secuencia o flujo de mensaje (como el flujo muestra la dirección).

Representa los participantes principales de un proceso, por lo general, separados por

las diferentes organizaciones. Una piscina contiene uno o más carriles (en la vida real,

como una piscina olímpica). Una piscina puede ser abierta (por ejemplo, mostrar el

detalle interno), cuando se presenta como un gran rectángulo que muestra uno o más

carriles, o cerrada (por ejemplo, esconder el detalle interno), cuando se presenta como

un rectángulo vacío que se extiende a lo ancho o alto del diagrama.

Mantenimiento de software En ingeniería del software, el mantenimiento de software es la modificación de un producto de software después de la entrega, para corregir errores, mejorar el rendimiento, u otros atributos.1 El mantenimiento del software es una de las actividades más comunes en la ingeniería de software.

El mantenimiento de software es también una de las fases en el ciclo de vida de desarrollo de sistemas (SDLC, sigla en inglés de system development life cycle), que se aplica al desarrollo de software. La fase de mantenimiento es la fase que viene después del despliegue (implementación) del software en el campo.

Una percepción común del mantenimiento es que se trata meramente de la corrección de defectos. Sin embargo, un estudio indicó que la mayoría, más del 80%, del esfuerzo de mantenimiento es usado para acciones no correctivas (Pigosky 1997). Esta percepción es perpetuada por usuarios enviando informes de problemas que en realidad son mejoras de funcionalidad al sistema[cita requerida].

El mantenimiento del software y la evolución de los sistemas fue abordada por primera vez por Meir M. Lehman en 1969. Durante un período de veinte años, su investigación condujo a la formulación de las leyes de Lehman (Lehman 1997). Principales conclusiones de su investigación incluyen que el mantenimiento es realmente un desarrollo evolutivo y que las decisiones de mantenimiento son ayudadas por entender lo que sucede a los sistemas (y al software) con el tiempo. Lehman demostró que los sistemas continúan evolucionando con el tiempo. A medida que evolucionan, ellos crecen más complejos a menos que se toman algunas medidas como refactorización de código para reducir la complejidad.

Los problemas claves de mantenimiento de software son administrativos y técnicos. Problemas clave de administración son: alineación con las prioridades del cliente, dotación de personal, cuál organización hace mantenimiento, estimación de costos. Son cuestiones técnicas claves: limitado entendimiento, análisis de impacto, pruebas (testing), medición de mantenibilidad.

El mantenimiento de software es una actividad muy amplia que incluye la corrección de errores, mejoras de las capacidades, eliminación de funciones obsoletas y optimización. Debido a que el cambio es inevitable, se debe desarrollar mecanismos para la evaluación, controlar y hacer modificaciones.

Así que cualquier trabajo realizado para cambiar el software después de que esté en operación es considerado trabajo de mantenimiento. El propósito es preservar el

valor del software sobre el tiempo. El valor puede ser mejorado ampliando la base de clientes, cumpliendo requisitos adicionales, siendo cada vez más fácil de usar, más eficiente y empleando más nuevas tecnología. El mantenimiento puede abarcar 20 años, mientras que el desarrollo puede estar entre 1 y 2 años.

Importancia del mantenimiento de software[editar]

A finales de los años 1970, una famosa y ampliamente citada estudio de encuesta por

Lientz y Swanson, expuso la muy alta fracción de los costos del ciclo de vida que

estaban siendo gastados en mantenimiento. Clasificaron las actividades de

mantenimiento en cuatro clases:

Adaptable – modificar el sistema para hacer frente a cambios en el ambiente del

software (DBMS, OS)2

Perfectivo – implementar nuevos, o cambiar requerimientos de usuario

referentes a mejoras funcionales para el software

Correctivo, diagnosticar y corregir errores, posiblemente los encontrados por los

usuarios2

Preventiva – aumentar la capacidad de mantenimiento de software o fiabilidad

para evitar problemas en el futuro2

La encuesta mostró que alrededor del 75% del esfuerzo de mantenimiento fue en los

dos primeros dos tipos, y la corrección de errores consumía aproximadamente el

21%. Muchos estudios posteriores sugieren una magnitud similar del problema. Los

estudios muestran que la contribución del usuario final es crucial durante el análisis

y recopilación de nuevos datos de requerimiento. Y ésta es la causa principal de

cualquier problema durante el mantenimiento y evolución del software. Así que el

mantenimiento de software es importante porque consume gran parte de los costos

del ciclo de vida y también la imposibilidad de cambiar el software de forma rápida

y fiable significa que las oportunidades de negocio se pierden. 3 4 5