ACTORES O ROLES

Son los personajes encargados de la realización de las actividades definidas dentro de los flujos de trabajo de cada una de las disciplinas del RUP, estos actores se dividen en varias categorías: Analistas, Desarrolladores, Probadores, Encargados, otros actores. A continuación se presenta una lista de actores de acorde a las categorías mencionadas con anterioridad:

Analistas

1. Analista del Proceso del Negocio2. Diseñador del Negocio3. Revisor del Modelo del Negocio4. Revisor de Requerimientos5. Analista del Sistema6. Especificador de Casos de Uso7. Diseñador de Interfaz de Usuario

Desarrolladores

1. Arquitecto2. Revisor de la Arquitectura3. Diseñador de Cápsulas4. Revisor del Código y Revisor del Diseño5. Diseñador de la Base de Datos6. Diseñador7. Implementador y un Integrador

Probadores Profesionales

1. Diseñador de Pruebas2. Probador

Encargados

1. Encargado de Control del Cambio2. Encargado de la Configuración3. Encargado del Despliegue4. Ingeniero de Procesos5. Encargado de Proyecto6. Revisor de Proyecto

Otros

1. Cualquier trabajador2. Artista Gráfico3. Stakeholder (en un proceso son actores personas u organizaciones con un interés

personal en la política que se promueven=4. Administrador del Sistema5. Escritor técnico6. Especialista de Herramientas

ARTEFACTOS

Los artefactos son el resultado parcial o final que es producido y usado por los actores durante el proyecto. Son las entradas y salidas de las actividades, realizadas por los actores, los cuales utilizan y van produciendo estos artefactos para tener guías. Un artefacto puede ser un documento, un modelo o un elemento de modelo.

Conjunto de Artefactos

Se tiene un conjunto de artefactos definidos en cada una de las disciplinas y utilizadas dentro de ellas por los actores para la realización de las mismas, a continuación se definen cada una de estas categorías o grupos de artefactos dentro de las disciplinas del RUP:

o Modelado del NegocioLos artefactos del modelado del negocio capturan y presentan el contexto del negocio del sistema. Los artefactos del modelado del negocio sirven como entrada y como referencia para los requisitos del sistema.

o RequerimientosLos artefactos de requerimientos del sistema capturan y presenta la información usada en definir las capacidades requeridas del sistema.

o Análisis y diseño del sistemaLos artefactos para el análisis y del diseño capturan y presenta la información relacionada con la solución a los problemas que se presentaron en los requisitos fijados.

o ImplementaciónLos artefactos para la implementación capturan y presentan la realización de la solución presentada en el análisis y diseño del sistema.

o PruebasLos artefactos desarrollados como productos de las actividades de prueba y de la evaluación son agrupadas por el actor responsable, con el cual se lleva un conjunto

de documentos de información sobre las pruebas realizadas y las metodologías de pruebas aplicadas.

o DespliegueLos artefactos del despliegue capturan y presentan la información relacionada con la transitividad del sistema, presentada en la implementación en el ambiente de la producción.

o Administrador del proyectoEl conjunto de artefactos de la administración del proyecto capturan los artefactos asociados con el proyecto, el planeamiento y a la ejecución del proceso.

o Administración de cambios y configuraciónLos artefactos de la configuración y administración del cambio capturan y presentan la información relacionada con la disciplina de configuración y administración del cambio.

o Entorno o AmbienteEl conjunto de artefactos del ambiente presentan los artefactos que se utilizan como dirección a través del desarrollo del sistema para asegurar la consistencia de todos los artefactos producidos.

o Grados de Finalización de ArtefactosConsiste en cuanto hemos finalizado del artefacto propuesto, con esto nos referimos por ejemplo, si definimos que vamos a utilizar un artefacto, este nos dice los lineamientos que necesita para ser completado, por lo tanto con grado de finalización nos referimos a cuántos de esos lineamientos del artefacto hemos completado o llenado, esto en cada una de las disciplinas, de acorde a la fase en que se encuentre.

o Grado de Finalización de ArtefactosCon esto se puede mostrar el aumento progresivo de los artefactos en cada disciplina en la fase dada, teniendo una idea un poco más amplia sobre el desenvolvimiento del proyecto hablando en términos de sus artefactos.

¿QUÉ ES UML?

El lenguaje de Modelamiento Unificado (Unified Modeling Language) Es el lenguaje que puede ser usado para modelar sistemas y hacerlos legibles. Esto implica que UML provee la habilidad de capturar las características de un sistema usando notaciones.

El Lenguaje Unificado de Modelado, UML es una notación estándar para el modelado de sistemas, software, resultado de una propuesta de estandarización promovida por el

consorcio OMG (Object Management Group), del cual forman parte las empresas mas importantes que se dedican al desarrollo de software, en 1996.

UML es un lenguaje de propósito general para el modelado orientado a objetos, que combina notaciones provenientes desde: Modelado Orientado Objetos, Modelado de Datos, Modelado de Componentes, Modelado de Flujos de Trabajo (workflows)

Descripción de los Diagramas

Un modelo captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle. Un diagrama es una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo con vértices conectados por arcos.

1- Diagrama de Casos de Uso: modela la funcionalidad del sistema agrupándola en descripciones de acciones ejecutadas por un sistema para obtener un resultado.

2- Diagrama de Clases: muestra las clases (descripciones de objetos que comparten características comunes) que componen el sistema y cómo se relacionan entre sí.

3- Diagrama de Objetos: muestra una serie de objetos (instancias de las clases) y sus relaciones.

4- Diagramas de Comportamiento: dentro de estos diagramas se encuentran:5- Diagrama de Estados: modela el comportamiento del sistema de acuerdo con

eventos.6- Diagrama de Actividades: simplifica el Diagrama de Estados modelando el

comportamiento mediante flujos de actividades. También se pueden utilizar caminos verticales para mostrar los responsables de cada actividad.

7- Diagramas de Interacción: Estos diagramas a su vez se dividen en 2 tipos de diagramas, según la interacción que enfatizan:a) Diagrama de Secuencia: enfatizan la interacción entre los objetos y los mensajes

que intercambian entre sí junto con el orden temporal de los mismos.b) Diagrama de Colaboración: igualmente, muestra la interacción entre los objetos

resaltando la organización estructural de los objetos en lugar del orden de los mensajes intercambiados.

8- Diagrama de implementación: a) Diagrama de Componentes: muestra la organización y las dependencias entre un

conjunto de componentes.b) Diagrama de Despliegue: muestra los dispositivos que se encuentran en un

sistema y su distribución en el mismo.

Metodología del RUP para análisis y diseño.

El RUP propone la utilización de los modelos para la implementación completa de todas sus fases respectivamente con sus disciplinas:

1. Modelo de Casos de Uso del Negocio: Describe la realización del Caso de Uso, es realizado en la disciplina de Modelado del Negocio.

2. Modelo de Objetos del Negocio: Se utiliza para identificar roles dentro de la organización, es realizado en la disciplina de Modelado del Negocio.

3. Modelo de Casos de Uso: Muestra las interrelaciones entre el sistema y su ambiente, además sirve como un contrato entre el cliente y los diseñadores. Es considerado esencial al iniciar las actividades del análisis, diseño y prueba; este modelo es realizado en la disciplina de Requerimientos.

4. Modelo de Análisis: Contiene los resultados del análisis del caso de uso, y contienen instancias del artefacto de análisis de clases; es realizado en la disciplina de análisis y diseño.

5. Modelo de Diseño: Es un modelo de objetos que describe la realización del caso de uso, y sirve como una abstracción del modelo de implementación y su código fuente, es utilizado como entrada en las actividades de implementación y prueba; este modelo se realiza en la disciplina de análisis y diseño.

6. Modelo de Despliegue: Muestra la configuración de los nodos del proceso en tiempo de ejecución, muestra los lazos de comunicación entre estos nodos, así como las de los objetos y componentes que en él se encuentran; es realizado en la disciplina de análisis y diseño.

7. Modelo de Datos: es un subconjunto del modelo de implementación que describe la representación lógica y física de datos persistentes en el sistema. también incluye cualquier conducta definida en la base de datos como disparadores, restricciones, etc. Es elaborado en la disciplina de análisis y diseño.

8. Modelo de Implementación: Es una colección de componentes, y de subsistemas de aplicación que contienen estos componentes, entre estos están los entregables, ejecutables, archivos de código fuente. Es realizado en la disciplina de implementación.

9. Modelo de Pruebas: Es utilizado para la elaboración de las pruebas, y se realiza en la disciplina de pruebas.

Las clases, al igual que los demás elementos notacionales del UML, pueden estar clasificadas de acuerdo a varios criterios, como por ejemplo su objetivo dentro de un programa. Esta clasificación adicional se puede expresar mediante la utilización de estereotipos.

Los estereotipos mas comunes utilizados para clasificar las clases son: Entidad (entity), Frontera (boundary), Control (control). Se proponen varias pautas a seguir a la ora de encontrar las clases de nuestro sistema durante la fase de análisis. Dichas pautas se centran en la búsqueda de los estereotipos entidad, control y frontera:

1. Una clase entidad modela la información de larga vida y su comportamiento asociado. Este tipo de clase suele reflejar comportamiento asociado. Este tipo de clase suele reflejar entidades del mundo real o elementos necesarios para realizar tareas internas al sistema. también se denominan clase de dominio, ya que suelen tratar con abstracciones de entidades del mundo real.

2. Una clase frontera maneja comunicaciones entre el entorno del sistema y el sistema, suelen proporcionar la interfaz del sistema con un usuario o con otro sistema, en general, por tanto, modelan las interfaces del sistema. cuando se trata de clases que definen la interfaz con otro sistema se refinarán durante la fase de diseño, para tener en cuenta los protocolos de comunicación elegidos.

3. Una clase controlo modela el comportamiento secuenciado específico de uno o varios casos de uso. Se trata de clases que coordinan los eventos necesarios para llevar a cabo el comportamiento que se especifica en el caso de uso, representan su dinámica.

Enlace del RUP con el UML

Conociendo los estereotipos utilizados para la representación de las clases (entidad, control y frontera), ahora podemos explicar la interrelación que existe entre el UML y RUP describiendo los diagramas que describe UML y como se convierte en diagramas del RUP que utilizan estos estereotipos.

El UML proporciona los diagramas de Caso de Uso, al mismo tiempo que el RUP, la única diferencia es la forma de dibujar los estereotipos, ya que el RUP son una elipse con una diagonal al lado derecho (pero esto es para casos de uso de negocio, los de sistema no tienen la diagonal), y en UML solamente una elipse, pero en el RUP significa lo mismo a lo que se refiere en UML.

Los diagramas de clases tienen la misma lógica para lo cual fueron creados en ambos lenguajes, solamente con las diferencias en la forma de dibujar los cuadros que indican las clases en RUP se dibujan los cuadro con una pestaña inferior derecha doblada, y en UML solamente rectángulos con ángulos rectos; otra característica que se puede observar es que a la hora de ejemplificar las relaciones uno a uno, uno a muchos etc., se realizan de diferente manera. Pero en ambos lenguajes se puede observar que los diagramas de

clases son lo más cercano a la elaboración de un modelo entidad relación para la puesta en práctica de la finalización del proyecto de software.

Los diagramas de objetos, difieren únicamente en la forma como se dibujan los objetos o instancias de las clases, ya que en el RUP se dibujan círculos con una diagonal en la parte inferior derecha, y en UML como rectángulos con las esquinas redondeadas, también en RUP no se colocan flechas indicativas, y en UML sí.

Los diagramas de estados en RUP y UML, se pueden observar que de igual manera se elaboran ambos, únicamente que en el diagrama de UML se muestran unos rectángulos con la esquina superior derecha doblada, que indican notas sobre este estado.

En los diagramas de actividades se utilizan todos los bloques utilizados en la elaboración de diagramas de flujo, por lo tanto en ambos lenguajes se utilizan los mismos.

En los diagramas de secuencia se pueden encontrar diferencias leves, los de UML no llevan los símbolos que identifican los estereotipos interface (círculos con una raya horizontal del lado izquierdo y junto a esta otra vertical), control (círculo con una flecha sobre su borde apuntando al lado izquierdo) y entidad (círculo con una raya horizontal en la parte inferior del mismo), representados por círculos con características independientes.

Los diagramas de colaboración se representan similares, con la única diferencia de los bloques que representan las clases, ya que en el RUP se representan por medio de los círculos con sus características individuales de acorde a la función que desempeñen (interfaz, control, entidad) y en UML solamente como rectángulos. En ambos se colocan las actividades que conllevan realizar para llegar a una clase determinada, a esto se coloca directamente en la flecha dibujada en la línea que va hacia la clase.

Dentro de los diagramas de implementación se encuentran los de componentes, los cuales representan de manera similar en ambos lenguajes.

La diferencia básica en los diagramas de despliegue es que en UML se dibujan dentro de las cajas los componentes utilizados, en cambio en el RUP se diagraman de forma separada.

Se puede observar en todos los diagramas presentados anteriormente que la similitud entre ambos lenguajes es demasiado grande, y es de esperar esto, ya que RUP utiliza los del UML y por lo tanto recopila todo lo que este lenguaje necesita para la implementación, y agrega mejoras, siendo una herramienta de modelado muy eficiente, ya que proporciona todas las herramientas necesarias para tal función, por lo tanto la funcionalidad completa de UML esta descrita e implementada por el RUP.

METODO RAD (PROTOTIPOS)

James Martin creó el término “Desarrollo Rápido de Aplicaciones” apuntando hacia una metodología y conjunto de herramientas específicos. Mientras tanto, hoy día se utilizan esta metodología y que intentar reducir el tiempo de desarrollo. Esta es una metodología y que intentan reducir el tiempo de desarrollo. Esta es una metodología que permite a las organizaciones desarrollar sistemas estratégicamente importantes, de manera más rápida reduciendo a la vez los costos de desarrollo y manteniendo la calidad. Esto se hace por medio de la automatización de porciones grandes del ciclo de vida del desarrollo de sistemas, imponiendo límites entre los plazos de desarrollo y volviendo a usar los componentes existentes y se logra mediante el uso de una serie de técnicas de utilidad comprobada de desarrollo de aplicaciones, dentro de una metodología bien definida. Algunas de estas tecnologías son:

1. JAD (Joint Application Development): pequeños grupos (hasta 10 personas) de usuarios y analistas hacen reuniones, para un corto espacio de tiempo analizar y especificar entradas, proceso y salidas, a través del desarrollo conjunto de un prototipo.

2. Generadores de Aplicación: estas herramientas posibilitan generar código ejecutable a partir de definiciones generales o prototipos. Son utilizadas como parte de un proceso mayor de JAD o prototipación. El mayor problema es la calidad (desempeño) del código generado, principalmente en un ambiente multiusuario.

3. Prototipación rápida: el objetivo de esta técnica es obtener en el menor tiempo posible el análisis, diseño e implementación de un sistema, completo o parcial, a través de la utilización de técnicas y tecnologías complementarias (JAD, generaciones de aplicación, etc)

4. Estas técnicas incluyen el uso de:a. Equipos pequeños de desarrollo y bien capacitados.b. Prototipos evolutivosc. Herramientas poderosas integradas que apoyan el modelo, el prototipo y la

reutilización de componentes.5. Un almacenamiento central de la información para tenerla a la mano en el momento

que se le necesita.6. Requisitos interactivos y talleres de diseño.7. Límites rígidos en los plazos de desarrollo.

Las herramientas gráficas orientadas a objetos tienen, casi todas, interiorizadas el concepto general de RAD. Además, con la creación bien planificada de objetos, la

programación de nuevos módulos se vuelve cada vez mas simplificada, reutilizando los objetos creados anteriormente.

Uno de los conceptos de RAD mas interesantes, y que provee mejores resultados prácticos, es el de “entrega incremental de productos”. La idea es detectar durante el análisis módulos del sistema que puedan ser desarrollados e implantados aisladamente y trabajar en este sentido, utilizando las técnicas descritas anteriormente.

Casos de Uso.

El diagrama de casos de uso sirve para identificar los elementos primarios y procesos que conforman el sistema.

Un actor puede representar un usuario, rol, otros sistemas.

Un caso de Uso es una secuencia de acciones que brinda el sistema a un actor particular.

Actores y casos de uso se relacionan mediante asociaciones o dependencias.

El propósito principal del modelo de caso de uso es comunicar la funcionalidad del sistema y la interacción con el usuario.

Diagrama de Clases.

El diagrama de clases es usado para refinar el diagrama de casos de uso y definir un diseño detallado del sistema.

Cada clase en el diagrama de clases puede almacenar valores y tiene capacidad de proveer ciertas funcionalidades, conocido como “atributos” y “métodos”.

Diagrama de Secuencia.

Un diagrama de secuencia representa la interacción entre diferentes objetos en el sistema. El aspecto importante de un diagrama de secuencia es que es ordenado en el tiempo. Los diferentes objetos del diagrama de secuencia interactúan entre ellos a través del paso de “mensajes”.

Especificaciones.

Un caso de uso es la descripción de una secuencia de interacciones entre el sistema y uno o más actores en la que se considera al sistema como una caja negra y en la que los actores obtienen resultados observables.

Los actores son personas u otros sistemas que interactúan con el sistema cuyos requisitos se están describiendo.

Los casos de uso presentan ciertas ventajas sobre la descripción meramente textual de los requisitos funcionales, ya que facilitan la eliminación de requisitos y son fácilmente compresibles por los clientes y usuarios. Además, puede servir de base a las pruebas del sistema y a la documentación para los usuarios.

PROCEDIMIENTO DE RESPALDO O BACK UP MODELOS DE ALMACENAMIENTO DE DATOS

Cualquier estrategia de copia de seguridad empieza con el concepto de almacén de datos.

Los datos de la copia deben ser almacenados de alguna manera y probablemente deban ser organizados con algún criterio. Para ello se puede usar desde una hoja de papel con una lista de cintas de la copia de seguridad y las fechas en que fueron hechas hasta un sofisticado programa con una base de datos relacional.

Cada uno de los distintos almacenes de datos tiene sus ventajas. Esto está muy relacionado con el esquema de rotación de copia de seguridad elegido.

Desestructurado.

Un almacén desestructurado podría ser simplemente una pila de disquetes o CD-R con una mínima información sobre qué ha sido copiado y cuándo. Esta es la forma más fácil de implementar, pero ofrece pocas garantías de recuperación de datos.

Completa + Incremental

Un almacén completo-incremental propone hacer más factible el almacenamiento de varias copias de la misma fuente de datos. En primer lugar se realiza la copia de seguridad completa del sistema. más tarde se realiza una copia de seguridad incremental, es decir, sólo con los archivos que se hayan modificado desde la última copia de seguridad. Recuperar y restaurar un sistema completamente a un cierto punto en el tiempo requiere localizar una copia de seguridad completa y todas las incrementales posteriores realizadas hasta el instante que se desea restaurar. Los inconvenientes son tener que tratar con grandes series de copias incrementales y contar con un gran espacio de almacenaje.

Espejo + Diferencial

Un almacén de tipo espejo + diferencial inversa es similar al almacén completo-incremental. La diferencia está en que en vez de hacer una copia completa seguida de series incrementales, este modelo ofrece un espejo que refleja el estado del sistema a partir de la última copia y un historial de copias diferenciales. Una ventaja de este modelo

es que solo requiere una copia de seguridad completa inicial. Cada copia diferencial es inmediatamente añadida al espejo y los ficheros que son remplazados son movidos a una copia incremental inversa. Una copia diferencial puede sustituir a otra copia diferencial mas antigua sobre la misma copia total.

Protección continua de datos.

Este modelo va un paso más allá y en lugar de realizar copias de seguridad periódicas, el sistema inmediatamente completas y posteriores incrementales. Es de gran utilidad sobre todo en redes de almacenamiento (SAN) ya que no es necesaria la participación del host/nodo final, quitándole mucha carga de proceso.

En línea.

El almacenamiento en línea es típicamente el mas accesible de los tipos de almacenamiento de datos. Un buen ejemplo sería un gran array de discos. Este tipo de almacenamiento es muy conveniente y rápido, pero es relativamente mas caro y está típicamente localizado cerca del sistema que pretende proteger. Esta proximidad es un problema en un caso de desastre. Además, el almacenamiento en línea es susceptible de ser borrado o sobre escrito, incluso por accidente, o por un virus en el sistema.

Cerca de Línea.

Almacenamiento cercado en línea es mas asequible y accesible que el almacenamiento en línea. Un buen ejemplo sería una biblioteca de cintas. Se necesita un dispositivo mecánico para mover las unidades de almacenamiento desde el almacén donde están hasta un lector donde son leídas o escritas.

Fuera de línea.

Un almacenamiento fuera de línea es similar al cercano en línea, exceptuando que necesita una persona interaccionado para hacer los medios de almacenamiento disponibles. Esto puede ser tan simple como almacenar las cintas de copia de seguridad en un armario de ficheros.

Centro de recuperación de datos.

En el momento de un desastre, la información de una copia de seguridad puede no ser suficiente para restaurar un sistema. Algunas organizaciones tienen sus propios centros de recuperación, que están equipados para estos casos.

Propuestas de copia de Seguridad de Datos.

Es decidir qué se van a incluir en la copia de seguridad es un proceso más complejo de lo que parece a priori.

Si copiamos muchos datos redundantes agotamos la capacidad de almacenamiento disponible rápidamente. Si no realizamos una copia de seguridad de los suficientes datos, podría perderse información crítica. La clave está en guardar copias de seguridad sólo de aquello que se ha modificado.

Depósito del Sistema de Archivos.

Copiar el sistema de archivos que tienen los archivos copiados. Esto normalmente implica desmontar el sistema de archivos y hacer funcionar un programa como un depósito. Esto es también conocido como copia de seguridad particionada en bruto. Este tipo de copia de seguridad tiene la posibilidad de hacer funcionar una copia más rápida que la simple copia de archivos. El rasgo de algunos software de depósitos es la habilidad para restaurar archivos específicos de la imagen del depósito.

Control de Cambios.

Algunos sistemas de archivos poseen un bit de archivo para cada fichero este nos indica si recientemente ha sido modificado. Algunos software de copia de seguridad miran la fecha del archivo y la comparan con la última copia de seguridad, para así determinar si el archivo se ha modificado.

Incremental a nivel de bloque

Un sistema mas sofisticado de copia de seguridad de ficheros ese el basado en solamente copiar los bloques físicos del fichero que han sufrido algunos cambios. Esto requiere un alto nivel de integración entre el sistema de ficheros y el software de la copia de seguridad.

Incremental o diferencial binaria.

Son tecnologías de backup que se desarrollan en la década de 2000. El método es similar a la Incremental a nivel de bloque, pero basada en reflejar las variaciones binarias que sufren los ficheros respecto al anterior backup. Mientras las tecnologías a nivel de bloque trabajan con unidades de cambio relativamente grandes (bloques de 8ks, 4ks, 1k) las tecnologías a nivel de byte trabajan con la unidad mínima capaz de ahorrar espacio para reflejar un cambio. Otra diferencia importante es que son independientes del sistema de archivos. Actualmente son las tecnologías que consiguen la máxima compresión relativa

de la información y ofrecen así una ventaja importante en las copias de seguridad a través de la Internet.

Versionando el sistema de archivos.

El versionado del sistema de archivos se mantiene atento a los cambios del fichero y crea estos cambios accesibles al usuario. Esta es una forma de copia de seguridad que está integrada al ambiente informático.

Copia de seguridad de datos en uso.

Si un servidor está en uso mientras se ejecuta su copia de seguridad, existe la posibilidad de que haya ficheros abiertos, ya que puede que se esté trabajando sobre ellos. Si un fichero está abierto, el contenido en el disco posiblemente no refleje exactamente lo que el usuario ve. Esto es especialmente frecuente en archivos de bases de datos.

Cuando se intenta atender la logística de la copia de seguridad de archivos abiertos, uno debe considerar que el proceso de copia de seguridad puede llevar varios minutos en copiar un gran archivo como una base de datos. A fin de copiar un fichero en uso, es vital que la copia de seguridad entera represente un único paso. Esto representa un reto cuando se está copiando un fichero en continua modificación. Aunque el archivo de base de datos esté bloqueado para evitar cambios, se debe implementar un método para asegurar que el original snapshot sea preservado con el tiempo de sobra para ser copiado, incluso cuando se mantengan los cambios.

Snapshot – Copia de Escritura.

El snapshot o copia instantánea de volumen, es una función de algunos sistemas que realizan copias de los ficheros como si estuvieran congelados en un momento determinado.

Copia de seguridad de archivos abiertos – Archivos Bloqueados

Algunos paquetes de software de copias de seguridad no poseen la capacidad de realizar copias de archivos abiertos. Simplemente comprueban que el archivo esté cerrado y si no lo está lo intentan mas tarde.

Copias de seguridad de base de datos en caliente.

Algunos sistemas de gestión de bases de datos ofrecen medios para realizar imágenes de copias de seguridad de una base de datos mientras esté activa y en uso (en caliente). Esto normalmente incluye una imagen consistente de los archivos de datos en un cierto momento más un registro de los cambios hechos mientras el algoritmo está funcionando.

El nacimiento de CMM – CMMI

El departamento de defensa de los estados unidos tenía muchos problemas con el software que encargaba desarrollar a otras empresas, los presupuestos se disparaban, las fechas alargaban mas y mas.

Como esta situación les parecía intolerable convocó un comité de expertos para que solucionase estos problemas, en el año 1983 dicho comité concluyó “Tienen que crear un instituto de la ingeniería del software, dedicado exclusivamente a los problemas del software, y a ayudar al Departamento de Defensa”.

Convocaron un concurso público en el que dijeron: “cualquiera que quiera enviar una solicitud tiene que explicar como van a resolver estos 4 problemas”, se presentaron diversos estamentos y la universidad Carnegie Mellon ganó el concurso en 1985 creando el SEI.

El SEI (software engineering institute) es el instituto que creó y mantiene el modelo de calidad CMM – CMMI

CMM – CMMI Capability Maturity Model Integration (CMMI) Integración de Modelos de Madurez de Capacidades o es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software.

Es un modelo de calidad del software que clasifica las empresas en niveles de madurez. Estos niveles sirven para conocer la madurez de los procesos que se realizan para producir software.

Niveles CMM – CMMI

Estos niveles son 5:

Inicial o Nivel 1 CMM – CMMI.

Este nivel es en donde están todas las empresas que no tienen procesos. Los presupuestos se disparan, no es posible entregar el proyecto en fechas, te tienes que quedar durante noches y fines de semana para terminar un proyecto. No hay control sobre el estado del proyecto, el desarrollo del proyecto ese completamente opaco, no sabes lo que pasa en él.

Si no sabes el tamaño del proyecto y no sabes cuanto llevas hecho, nunca sabrás cuando vas a terminar.

Repetible o Nivel 2 CMM – CMMI.

Quiere decir que el éxito de los resultados obtenidos se puede repetir. La principal diferencia entre este niel y el anterior es que el proyecto es gestionado y controlado durante el desarrollo del mismo. El desarrollo no es opaco y se pude saber el estado del proyecto en todo momento.

Los proceso que hay que implantar para alcanzar este nivel son:

1. Gestión de Requisitos2. Planificación de Proyectos3. Seguimiento y control de proyectos4. Gestión de proveedores5. Aseguramiento de la calidad6. Gestión de la configuración

Definido o Nivel 3 CMM – CMMI.

Resumiéndolo mucho, alcanzar este nivel significa que la forma de desarrollar proyectos (gestión e ingeniería) esta definida, por definida quiere decir que está establecida, documentada y que existen métricas (obtención de datos objetivos) para la consecución de objetivos concretos.

Los procesos que hay que implantar para alcanzar este nivel son:

1. Desarrollo de requisitos2. Solución Técnica3. Integración del producto4. Verificación5. Validación6. Desarrollo y mejora de los procesos de la organización7. Definición de los procesos de la organización8. Planificación de la formación9. Gestión de riesgos10. Análisis y resolución de toma de decisiones

La mayoría de las empresas que llegan al nivel 4 y paran aquí, ya que es un nivel que proporciona muchos beneficios y no ven la necesidad de ir mas allá porque tienen cubiertas la mayoría de sus necesidades.

Cuantitativamente Gestionado o Nivel 4 CMM – CMMI.

Los proyectos usan objetivos medibles para alcanzar las necesidades de los clientes y la organización. Se usan métricas para gestionar la organización.

Los procesos que hay que implantar para alcanzar este nivel son:

1. Gestión cuantitativa de proyectos2. Mejora de los procesos de la organización

Optimizado o Nivel 5 CMM – CMMI.

Los procesos de los proyectos y de la organización están orientados a la mejora de las actividades. Mejoras incrementales e innovadoras de los procesos que mediante métricas identificadas, evaluadas y puestas en práctica.

Los procesos que hay que implantar para alcanzar este nivel son:

1. Innovación organizacional2. Análisis y resolución de las causas

Normalmente las empresas que intentan alcanzar los niveles 4 y 5 lo realizan simultáneamente y a que están muy relacionados.

Áreas de Proceso

El modelo CMMI v1.2 (CMMI-DEV) contiene las siguientes 22 áreas de proceso:

1. Análisis de Causas y Resolución CAR2. Gestión de la configuración CM3. Análisis de Decisiones y Resolución DAR4. Gestión Integrada de Proyectos IPM5. Medición y Análisis MA6. Innovación y Despliegue Organizacionales OID7. Definición de procesos organizacionales OPD8. Enfoque Organizacional OPF9. Rendimiento de Procesos Organizacionales OPP10. Formación Organizacional OT11. Monitorización y Control de Proyecto PMC12. Planificación de proyecto PP13. Aseguramiento de calidad de procesos y productos PPQA14. Integración de Producto PI15. Gestión Cuantitativa de Proyectos QPM

16. Gestión de Requerimientos REQM17. Desarrollo de Requerimientos RD18. Gestión de Riesgos RSKM19. Gestión de Acuerdos con Proveedores SAM20. Solución Técnica TS21. Validación VAL22. Verificación VER

La implantación de un modelo de estas características es un proceso largo y costoso que puede costar varios años de esfuerzo. Aún así el beneficio obtenido para la empresa es mucho mayor que lo invertido.

Framework

En el desarrollo de software, un framework es una estructura de soporte definida en la cual otro proyecto de software puede ser organizado y desarrollado. Típicamente, un framework puede incluir soporte de programas, bibliotecas y un lenguaje de scripting entre otros software para ayudar a desarrollar y unir los diferentes componentes de un proyecto.

Un framework representa una arquitectura de software que modela las relaciones generales de las entidades del dominio. Provee una estructura y una metodología de trabajo la cual extiende o utiliza las aplicaciones dominio.

Pero más allá, y proyectando una definición de framework a nivel empresarial podemos decir que es una estructura en la cual cada componente de la empresa u organización esta en comunicación e interactuando con las demás partes de la misma, y que se puede modificar incorporar o remover alguna parte de dicha infraestructura, de tal forma que sea un ente vivo y que permita con suficiente flexibilidad transformar la misma estructura.

Zachman Framework Es conocido por una sólida historia ayudando a las organizaciones a acortejar, organizar y estructurar su capital intelectual.

Con un conjunto de características incluidas dentro de la herramienta base de modelado – el Zachman Framework cobra vida para proveerle un MGD Technology for Zachman Framework:

o Provee una potente herramienta de planificación para la empresao Ayuda a alinear el negocio con la TI al proveer trazabilidad de extremo a extremo

desde objetivos estratégicos de negocio a soluciones implementadas.

o Simplifica la documentación de la empresa con modelos visuales que son construidos con estándares abiertos y son fácilmente entendibles por personas que no son del ámbito TI

o Provee una visión integrada y escalable de la documentación de la arquitectura de la empresa.

Características:

o Una interfaz visual atractiva para el Zachman Frameworko Estructuras de modelo jerárquicas que soportan cada celda dentro del marco de

trabajoo Perfiles UML para tablero de comandos, mapas conceptuales y modelado de

procesos de negocio.o Modelos de inicio para ayudarlo a ser productivo rápidamenteo Validación específica para el macro de trabajo, para asegurar la consistencia y

correctitud.o Reportes y generación de mapas de proceso para facilitar el planeamiento

estratégico.o Modelo de ejemplo detallado.

Arquitectura Empresarial

John Zachman escribió en 1987, para cuidar el negocio de una desaparición, el concepto de la arquitectura de los sistemas de información se esta convirtiendo menos en una opción y mas en una necesidad.

El framework de Zachman es el siguiente:

Lo cual representa los datos, funciones, red, gente, tiempo y motivación de:

1. Los objetivos2. Modelo del negocio3. Modelo del sistema de información4. Modelo de la tecnología5. Arquitectura6. Y sistema funcional

Donde cada una de las intersecciones de la matriz o framework de Zachman, son en sí frameworks o modelos.

En otras palabras, se hace un estudio de donde se encuentra la empresa, que hace y a donde se quiere llegar, documentando cada rincón de la misma y con la visualización

correcta proponer, desarrollar e implementar el nuevo paradigma para la empresa que le permita estar preparada y ser mas eficiente.

La integridad Social

Bajo el nombre de Ingeniería Social se encuentran comprendidas todas aquellas conductas útiles para conseguir información de las personas cercanas a una computadora. Es una disciplina que consiste, ni mas ni menos en sacar información a otra persona sin que esta se dé cuenta de que te está revelando “información sensible”.

La principal herramienta que manejan actualmente los creadores de virus es la que se ha dado en llamar ingeniería social. Con este curioso término se engloba una serie de tretas, artimañas y engaños elaborados cuyo fin es confundir al usuario o peor todavía lograr que comprometa seriamente la seguridad de sus sistemas. Esto no es un conocimiento exacto pero, al ponerse en práctica con un grupo tan elevado de posibles víctimas, el éxito casi siempre está garantizado. Aprovechando sentimientos tan variados como la curiosidad, la avaricia, el sexo, la compasión o el medio, el vándalo interesado consigue su objetivo, una acción por parte del usuario.

La ingeniería social es una acción muy simple, pero peligrosa. Los “hackers” llaman a los centros de datos y fingen ser un cliente que perdió su contraseña, o se dirigen a un sitio y esperan que alguien deje la puerta abierta. Otras formas de ingeniería social no son tan obvias. Los “hackers” son conocidos por crear sitios web, concursos o cuestionarios falsos que piden a los usuarios que ingresen una contraseña. Si un usuario escribe la misma contraseña que usa en su trabajo, el hacker puede ingresar en las instalaciones sin tener que descifrar ni siquiera una línea de código.

En la práctica, los autores de virus (gusanos o troyanos) emplean la Ingeniería Social para que sus creaciones se propaguen rápidamente. Para ello traen la atención del usuario y consiguen que realice alguna acción que, normalmente, consiste en inducirlo a que abra algún archivo que es el que procede a realizar la infección. De hecho, la mayoría de las pérdidas provocadas por los efectos de los códigos maliciosos tienen su origen en la ignorancia u omisión de políticas de seguridad.

El personal de una empresa debería de seguir las siguientes recomendaciones para evitar caer víctima de las trampas de la Ingeniería Social:

1. Antes de abrir los correos analizarlos con un antivirus eficaz y debidamente actualizado, ya que cualquier mensaje de correo electrónico puede contener códigos maliciosos aunque no le acompañe el símbolo de datos adjuntos.

2. Nunca ejecutar un programa de precedencia desconocida, aun cuando previamente sea verificado que no contiene virus. Dicho programa puede contener un troyano o un sniffer que reenvie nuestra clave de acceso.

3. Los usuarios no necesitan tener acceso a todo tipo de ficheros ya que no todos son necesarios para su trabajo habitual, por ello puede ser conveniente por parte del administrador bloquear la entrada de ficheros con extensiones “.exe”, “.vbs”. etc.

4. Nunca informe telefónicamente de las características técnicas de la red, sus localizaciones espaciales o personas a cargo de la misma. En su lugar lo propio es remitirlos directamente al responsable del sistema.

5. Controlar los accesos físicos al lugar donde se hallan los servidores o terminales desde los que se pueden conectar con los servicios centralizados de control.

6. Nunca tirar documentación técnica a la basura, sino destruirla.7. Verificar previamente la veracidad de la fuente que solicite cualquier información

sobre la red, su localización en tiempo y espacio y las personas que se encuentren al frente de la misma.

8. En caso de existir, instalar los parches de actualización de software que publican las compañías para solucionar vulnerabilidades. De esta manera se puede hacer frente a los efectos que puede provocar la ejecución de archivos con códigos maliciosos.

9. Controlar que las anteriores instrucciones se cumplen sistemáticamente.

PLANES DE CONTINGENCIA

MAINGRAME

Introducción a J2EE

J2EE, la plataforma creada por SUN en el año 1997 es la que ofrece perspectivas de desarrollo para empresas que quieran basar su arquitectura en productos basados en software libre.

JRS es el acrónimo de JAVA Specification Request. Cuando una persona o entidad cree que es necesaria la presencia de una determinada tecnología dentro de las plataformas basadas en Java, lo que hace es crear un JSR y presentarlo para su aprobación.

JCP tiene como fin controlar la evolución de las diferentes especificaciones que forman las plataformas basadas en Java. Este organismo es el encargado de decidir que especificaciones aprueban y de controlar las fases por las que pasan.

J2EE es una especificación, JSR (concretamente el JSR-151) que define una plataforma de desarrollo empresarial, a la que llamaremos la plataforma J2EE. La plataforma J2EE está

formada de varios componentes: Un conjunto de especificaciones que relatan por que es necesaria dicha tecnología y que problemas va a solucionar.