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 Negocio

2. Diseñador del Negocio
3. Revisor del Modelo del Negocio
4. Revisor de Requerimientos
5. Analista del Sistema
6. Especificador de Casos de Uso
7. Diseñador de Interfaz de Usuario

Desarrolladores

1. Arquitecto
2. Revisor de la Arquitectura
3. Diseñador de Cápsulas
4. Revisor del Código y Revisor del Diseño
5. Diseñador de la Base de Datos
6. Diseñador
7. Implementador y un Integrador

Probadores Profesionales

1. Diseñador de Pruebas
2. Probador

Encargados

1. Encargado de Control del Cambio

2. Encargado de la Configuración
3. Encargado del Despliegue
4. Ingeniero de Procesos
5. Encargado de Proyecto
6. Revisor de Proyecto
Otros

1. Cualquier trabajador
2. Artista Gráfico
3. Stakeholder (en un proceso son actores personas u organizaciones con un interés
personal en la política que se promueven=
4. Administrador del Sistema
5. Escritor técnico
6. 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 Negocio

Los 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 Requerimientos
Los 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 sistema
Los 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ón
Los 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 Pruebas
Los 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 Despliegue
Los 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 proyecto
El 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ón
Los 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 Ambiente
El 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 Artefactos
Consiste 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 Artefactos
Con 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 evolutivos
c. 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 Requisitos
2. Planificación de Proyectos
3. Seguimiento y control de proyectos
4. Gestión de proveedores
5. Aseguramiento de la calidad
6. 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 requisitos
2. Solución Técnica
3. Integración del producto
4. Verificación
5. Validación
6. Desarrollo y mejora de los procesos de la organización
7. Definición de los procesos de la organización
8. Planificación de la formación
9. Gestión de riesgos
10. 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 proyectos

2. 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 organizacional
2. 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 CAR

2. Gestión de la configuración CM
3. Análisis de Decisiones y Resolución DAR
4. Gestión Integrada de Proyectos IPM
5. Medición y Análisis MA
6. Innovación y Despliegue Organizacionales OID
7. Definición de procesos organizacionales OPD
8. Enfoque Organizacional OPF
9. Rendimiento de Procesos Organizacionales OPP
10. Formación Organizacional OT
11. Monitorización y Control de Proyecto PMC
12. Planificación de proyecto PP
13. Aseguramiento de calidad de procesos y productos PPQA
14. Integración de Producto PI
15. Gestión Cuantitativa de Proyectos QPM
 16. Gestión de Requerimientos REQM
17. Desarrollo de Requerimientos RD
18. Gestión de Riesgos RSKM
19. Gestión de Acuerdos con Proveedores SAM
20. Solución Técnica TS
21. Validación VAL
22. 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 empresa

o 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 Framework

o Estructuras de modelo jerárquicas que soportan cada celda dentro del marco de
trabajo
o Perfiles UML para tablero de comandos, mapas conceptuales y modelado de
procesos de negocio.
o Modelos de inicio para ayudarlo a ser productivo rápidamente
o 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 objetivos
2. Modelo del negocio
3. Modelo del sistema de información
4. Modelo de la tecnología
5. Arquitectura
6. 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.