1.1.

GENERALIDADES

Este capítulo está relacionado con la revisión de textos, libros y artículos tomando en cuenta

conceptos básicos importantes para aprender y encarar el problema del cual trata el presente

Proyecto de Grado, nos referimos a definiciones de procesos y métodos de desarrollo orientados a

objetos y también a la notación UML, contemplados para la elaboración de aplicaciones Web y

seguridad.

1.2. DESCRIPCIÓN DEL SERVICIO

El Notario es la persona autorizada que conforme a derecho, da fe instrumental de los hechos,

actos y negocios jurídicos del derecho privado, realizados voluntaria y bilateralmente en acuerdo

autónomo. (Ver Anexo 1).

1.3. ORGANIZACIÓN

La Notaria se compone en cuatro entidades en forma general y cada una son independientes de

ellas mismas. (Ver Anexo 2).

1.3.1. OBJETIVO INSTITUCIONAL

Los siguientes deberes específicos del Notario: Deber de asesoramiento, de certificación y

autorización, de conservación, de ética profesional, de obtención de litigio, de eficiencia

profesional, de secreto profesional, de cobro adecuado y deber de competencia leal.

Las disposiciones legales referentes a la residencia de los Notarios están Contempladas en los

artículos 6 y 7 de la Ley del Notariado. [BO-L-18580305][Bolivia, El Honorable Congreso

Nacional, (1858), Ley del Notariado, La Paz: HCN]

14
1.3.2. NOTARIAS Y NOTARIOS

[Bolivia, La Asamblea Legislativa Plurinacional, (2014), Ley del Notariado Plurinacional, La

Paz: ALP]

Título II

Notarias y notarios

Capítulo I

Notaria o Notario de fe pública

Artículo 11°.- (Notaria o notario de fe pública)

I. Es el profesional de derecho que cumple el servicio notarial por delegación del Estado y

la ejerce de forma privada, asesorando excepcionalmente en el marco de sus funciones,

interpretando y dando forma legal a la voluntad de las y los interesados, elaborando y

redactando los instrumentos públicos, asimismo realizará los trámites en la vía

voluntaria notarial previstos en la presente Ley.

II. Deberá fijar su residencia permanente en el ámbito territorial de su nombramiento o en

una localidad próxima.

1.4. RECOLECCIÓN DE INFORMACIÓN

Para la realización del presente trabajo ha sido necesaria la recolección de los datos, como la

entrevista al directo actor de la Notaria o Notario, responsable de los eventos y procesos que

suceden; también la observación de actividad Notarial, lo que permite cuantificar los problemas y

las necesidades de cambio.

15
1.4.1 ACTIVIDAD NOTARIAL

 Atención al Cliente

 Admisión, Protocolización y Normalización de los Trámites

 Entrega y/o Re poción de Trámites

 Validación y/o Certificación de Trámites

 Archivo de Trámites

1.4.2. NORMATIVAS DE DOCUMENTOS Y TRÁMITES

En la Normativas de Documentos y Trámites, los notarios tienes varios artículos los cuales se les

indica la manera de proceder y actuar, para evitar malos entendidos y/o errores. (Ver Anexo 3).

1.4.3. TIPOS DE DOCUMENTOS Y TRÁMITES

MODELO DE CONTRATOS

A continuación, sin intentar constituir formulas sacramentales,

únicamente con el afán de orientar, les presentamos diferentes modelo

de contratos:

 VENTA DE INMUEBLES: Venta directa, Venta mediante

apoderado, Venta con reserva de derecho de propiedad,

Compromiso de venta con arras penitenciales, División y

partición, Rescisión de contrato de venta, etc.

 VENTA DE VEHÍCULOS: De persona a persona, mediante

Poder Expreso, Venta por el apoderado a sí mismo

expresamente autorizado, Venta con pacto de Rescate o

retroventa, Arrendamiento mercantil de vehículo, etc.

16
  CONTRATOS DE ALQUILER Y ANTICRÉTICO:

Alquiler, Anticrético, Albergue, Cancelaciones.

 CONSTITUCIONES DE SOCIEDAD: De Responsabilidad

Limitada, Sociedad Anónima, Accidental etc.

 CONTRATO de PRÉSTAMO, CANCELACIÓN y

OTROS: Contratos Privados de préstamo, minutas de

préstamo, documentos con proyección a cobro ejecutivo, con

proyección a cobro por vía del proceso coactivo civil,

Cancelaciones, Subrogación de obligación, etc.

 RECONOCIMIENTO DE HIJO: Del ya nacido, de hijo Ad

Vientre.

 CAPITULACIÓN MATRIMONIAL: Trámite

 ANTICIPO DE LEGITIMA: Trámite

 TESTAMENTO ABIERTO: Testamentos, Revocatorias.

 DECLARACIÓN DE SOLVENCIA

ECONÓMICA: Trámite

 TRASFERENCIAS DE LÍNEA Y ACCIÓN

TELEFÓNICA: Venta, Cesión, transferencia de Línea con

devolución de dineros de cuotas pagadas, etc.

Tabla 1 – 1: Modelos de Contratos

Fuente: http://www.notariosbolivia.com

1.4.4. REQUISITOS PARA LOS TRÁMITES NOTARIALES

En la etapa de realización de algún trámite notarial, se solicitan diferentes requisitos, que se

detalla a continuación.

17
 DESCRIPCIÓN DE REQUISITOS PARA DIFERENTES TRÁMITES QUE

REALIZA UN NOTARIO

REQUISITOS PARA EFECTUAR INVENTARIOS NOTARIALES

 ORDEN JUDICIAL DE INVENTARIACION NOTARIAL.

 DOCUMENTOS QUE ACREDITEN SU INTERES LEGAL.

 CEDULA DE IDENTIDAD DEL (DE LOS) SOLICITANTE (S)

ORIGINALES Y FOTOCOPIAS.

REQUISITOS PROTESTOS DE LETRAS DE CAMBIO Y PAGARÉS

 LETRA DE CAMBIO ORIGINAL O PAGARE CORRECTAMENTE

SUSCRITA Y FOTOCOPIA DE LA MISMA.

 NOTIFICACION O CONMINATORIA DE PAGO QUE DEBE

EFECTUARSE CON LA ANTICIPACION DE 3 DIAS ANTES DEL

FENCIMIENTO DE LA FECHA ESTABLECIDA PARA EL PAGO.

 PRESENCIA DEL INTERESADO CON SU CEDULA DE IDENTIDAD Y

FOTOCOPIA DE LA MISMA.

REQUISITOS RECONOCIMIENTO DE FIRMAS

 DOCUMENTO PRIVADO.- ORIGINAL Y UNA COPIA PARA LA

NOTARIA O MINUTA CON CLAUSULA EXPRESA DE CONVERSION

CON UNA COPIA PARA LA NOTARIA.

 FOTOCOPIAS DE LAS CEDULAS DE IDENTIDAD DE LOS

INTERVINIENTES QUE RECONOCERAN SUS FIRMAS Y RUBRICAS.

18
 COMPARECIENTES.

 PRESENCIA DE LOS COMPARECIENTES CON SUS CEDULAS DE

IDENTIDAD ORIGINALES.

REQUISITOS PARA LA PROTOCOLIZACION DE ESCRITURAS PÚBLICAS

COMPRA VENTA (INMUEBLES, VEHICULOS, LINEAS TELEFONICAS).

 MINUTA ORIGINAL.

 PAGO DE IMPUESTOS A LA TRANSFERENCIA ORIGINAL (FORM. 502

O FORM. 430 DEPENDIENTO DEL CASO).

 FOTOCOPIA DE LAS CÉDULAS DE IDENTIDAD DE LOS

OMPARECIENTOS VENDEDOR Y COMPRADOR.

 PRESENCIA DE LAS PARTES CON SUS CEDULAS DE IDENTIDAD

ORIGINALES.

REQUISITOS PARA LA PROTOCOLIZACION DE ESCRITURAS DE

CONSTITUCION DE SOCIEDADES ANONIMAS, SOCIEDADES DE

RESPONZABILIDAD LIMITADA, COLECTIVAS, Y OTROS TIPOS

SOCIETARIOS ESTABLECIDOS EN EL ART. 36 Y SIGUIENTES DEL

CODIGO DE COMERCIO.

 MINUTA DE CONSTITUCION.- ORIGINAL.

 COPIA LEGALIZADA DEL ACTA DE CONSTITUCION DE LA

SOCIEDAD.

 FOTOCOPIAS DE CEDULAS DE IDENTIDAD DE LOS SOCIOS O

ACCIONISTAS SEGÚN EL CASO.

19
  PRESENCIA DE LAS PARTES CON SUS CEDULAS DE IDENTIDAD

ORIGINALES.

PODERES GENERALES DE ADMISTRACION (S.R.L., S.A. O OTROS TIPOS

SOCIETARIOS)

 INSTRUCTIVA (NO IMPRESINDIBLE)

 ACTA DE REUNION ORDINARIA DE ACCIONISTAS O ASAMBLEA DE

SOCIOS SEGÚN EL TIPO SOCIETARIO.

 FOTOCOPIAS DE CEDULAS DE IDENTIDAD DE LOS SOCIOS O

ACCIONISTAS SEGÚN EL CASO.

 PRESENCIA DE LOS ACCIONISTAS O SOCIOS CON SUS CEDULAS

 DE IDENTIDAD ORIGINALES.

TRANSFORMACION DE EMPRESAS, AUMENTO O DISMINUCION DE

CAPITAL, INGRESO DE NUEVO SOCIO.

 MINUTA DE CONSTITUCION.- ORIGINAL.

 COPIA LEGALIZADA DEL ACTA REUNION EXTRAORDINARIA DE

ACCIONISTAS OASAMBLEA DE SOCIOS SEGÚN EL CASO.

 FOTOCOPIAS DE CEDULAS DE IDENTIDAD DE LOS SOCIOS O

ACCIONISTAS SEGÚN EL CASO.

 PRESENCIA DE LAS PARTES CON SUS CEDULAS DE IDENTIDAD

ORIGINALES.

20
 REQUISITOS TESTAMENTOS

 PRESENCIA DEL TESTADOR CON SU CEDULA DE IDENTIDAD

ORIGINAL Y FOTOCOPIAS.

 PRESENCIA DE 3 TESTIGOS TESTAMENTARIOS CON SUS CEDULAS

DE IDENTIDAD ORIGINALES Y FOTOCOPIAS.

 DOCUMENTACION PROPIETARIA DE LOS BIENES MUEBLES O

INMUEBLES O ACCIONES

Tabla 1 – 2: Lista de Requisitos

Fuente: http://www.notariosbolivia.com

1.5. ANÁLISIS DE PROCESOS

1.5.1. RECUROS QUE INTERVIENEN EN LOS PROCESOS NOTARIALES

En los procesos notariales que se ejecutan son varios:

 INVENTARIOS NOTARIALES

 PROTESTOS DE LETRAS DE CAMBIO Y PAGARÉS

 RECONOCIMIENTO DE FIRMAS

 LA PROTOCOLIZACION DE ESCRITURAS PUBLICAS COMPRA VENTA

(INMUEBLES, VEHICULOS, LINEAS TELEFONICAS)

 REQUISITOS PARA LA PROTOCOLIZACION DE ESCRITURAS DE

CONSTITUCION DE SOCIEDADES ANONIMAS, SOCIEDADES DE

RESPONZABILIDAD LIMITADA, COLECTIVAS, Y OTROS TIPOS

SOCIETARIOS ESTABLECIDOS EN EL ART. 36 Y SIGUIENTES DEL

CODIGO DE COMERCIO.

 PODERES ESPECIALES Y GENERALES (DE PERSONA A PERSONA)

 PODERES GENERALES DE ADMISTRACION (S.R.L., S.A. O OTROS

21
 TIPOS SOCIETARIOS)

 TRANSFORMACION DE EMPRESAS, AUMENTO O DISMINUCION DE

CAPITAL, INGRESO DE NUEVO SOCIO

 TESTAMENTOS

1.5.2. PROCESOS DE PREPARACIÓN

En todos los trámites y acciones notariales están:

 Actores involucrados: El notario y cliente(s).

 Proceso: Identifican al cliente y redactan el trámite que se solicite.

 Documentos: Extensión, validación, comprobación de trámites y documentos.

1.6. EL PROCESO UNIFICADO (RUP)

1.6.1. HISTORIA

El antecedente más importante se ubica en 1967 con la Metodología Ericsson (Ericsson

Approach) elaborada por Ivar Jacobson, una aproximación de desarrollo basada en componentes,

que introdujo el concepto de Caso de Uso.

Entre los años de 1987 a 1995 Jacobson fundó la compañía Objectory AB y lanza el proceso de

desarrollo Objectory (abreviación de Object Factory).

Como se muestra en la figura 1 – 1 se muestra la evolución del proceso unificado (RUP)

secuencialmente desde el año 1967 hasta el 2001.

22
 Figura 1 – 1: Historia del RUP
Fuente: http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational

Posteriormente en 1995 Rational Software Corporation adquiere Objectory AB y entre

1995 y 1997 se desarrolla Rational Objectory Process (ROP) a partir de Objectory 3.8 y

del Enfoque Rational (Rational Approach) adoptando UML como lenguaje de modelado.

Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y James Rumbaugh, Rational

Software desarrolló e incorporó diversos elementos para expandir ROP, destacándose

especialmente el flujo de trabajo conocido como modelado del negocio. En junio del 1998 se

lanza Rational Unified Process.

1.6.2. CARACTERÍSTICAS ESENCIALES

Los autores de RUP destacan que el proceso de software propuesto por RUP tiene tres

características esenciales: está dirigido por los Casos de Uso, está centrado en la arquitectura, y es

iterativo e incremental. [JACOBSON, I., BOOCH G. y RUMBAUCH J. 2000]

23
1.6.3. PROCESO DIRIGIDO POR CASOS DE USO

Los Casos de Uso son una técnica de captura de requisitos que fuerza a pensar en términos de

importancia para el usuario y no sólo en términos de funciones que sería bueno contemplar. Se

define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al

usuario un valor añadido. Los casos de uso representan los requisitos funcionales del sistema,

también guían su diseño, implementación y prueba, los casos de so constituyen un elemento

integrador y una guía del trabajo. [JACOBSON et al., 2000]

Figura 1 – 2: Los Casos de Uso Integran el Trabajo

Fuente: http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational

Como de muestra en la Figura 1 – 2, los casos de uso integran el trabajo mediante requisitos,

análisis y diseño, implementación y pruebas.

Como se muestra en la Figura 1 – 3, basándose en los casos de uso se crean los modelos de

análisis y diseño, luego la implementación que los lleva a cabo, y se verifica que

efectivamente el producto implemente adecuadamente cada caso de uso. Todos los modelos

deben estar sincronizados con el modelo de casos de uso.

24
 Figura 1 – 3: Flujo a partir de los Casos de Uso
Fuente: http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational

1.6.4. PROCESO CENTRADO EN LA ARQUITECTURA

La arquitectura de un sistema es la organización o estructura de sus partes más relevantes, lo que

permite tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una

perspectiva clara del sistema completo, necesaria para controlar el desarrollo.

1.6.5. PROCESO ITERATIVO E INCREMENTAL

El equilibrio correcto entre los Casos de Uso y la arquitectura es algo muy parecido al

equilibrio de la forma y la función en el desarrollo del producto, lo cual se consigue con el

tiempo. Para esto, la estrategia que se propone en RUP es tener un proceso iterativo e

incremental en donde el trabajo se divide en partes más pequeñas o mini proyectos. Permitiendo

que el equilibrio entre Casos de Uso y arquitectura se vaya logrando durante cada mini

proyecto, así durante todo el proceso de desarrollo. Cada mini proyecto se puede ver como una

iteración (un recorrido más o menos completo a lo largo de todos los flujos de trabajo

fundamentales) del cual se obtiene un incremento que produce un crecimiento en el producto.

Una iteración puede realizarse por medio de una cascada de etapas como se muestra en la

Figura 1 – 4. Se pasa por los flujos fundamentales (Requisitos, Análisis, Diseño,

Implementación y Pruebas), también existe una planificación de la iteración, un análisis de la

25
iteración y algunas actividades específicas de la iteración. Al finalizar se realiza una integración

de los resultados con lo obtenido de las iteraciones anteriores.

Figura 1 – 4: Una Iteración RUP

Fuente: http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational

1.7. ESTRUCTURA DINÁMICA DEL PROCESO FASES E ITERACIONES

RUP se repite a lo largo de una serie de ciclos que constituyen la vida de un producto. Cada ciclo

concluye con una generación del producto para los clientes. Cada ciclo consta de cuatro fases:

Inicio, Elaboración, Construcción y Transición. Cada fase se subdivide a la vez en iteraciones, el

número de iteraciones en cada fase es variable.

Cada fase se concluye con un hito bien definido, un punto en el tiempo en el cual se deben tomar

ciertas decisiones críticas y alcanzar las metas clave antes de pasar a la siguiente fase, ese hito

principal de cada fase se compone de hitos menores que podrían ser los criterios aplicables a

cada iteración. Los hitos para cada una de las fases son: Inicio - Lifecycle Objectives,

Elaboración - Lifecycle Architecture, Construcción - Initial Operational Capability, Transición -

Product Release.

26
 Inicio

Durante la fase de inicio se define el modelo del negocio y el alcance del proyecto. Se identifican

todos los actores y Casos de Uso, y se diseñan los Casos de Uso más esenciales.

[KRUCHENTEN, P. 2000]

Los objetivos de está fase son:

 Establecer el ámbito del proyecto y sus límites.

 Encontrar los Casos de Uso críticos del sistema, los escenarios básicos que

definen la funcionalidad.

 Mostrar al menos una arquitectura candidata para los escenarios principales.

 Estimar el coste en recursos y tiempo de todo el proyecto.

 Estimar los riesgos, las fuentes de incertidumbre.

 Elaboración

El propósito de la fase de elaboración es analizar el dominio del problema, establecer los

cimientos de la arquitectura, desarrollar el plan del proyecto y eliminar los mayores riesgos.

En esta fase se construye un prototipo de la arquitectura, que debe evolucionar en iteraciones

sucesivas hasta convertirse en el sistema final. Este prototipo debe contener los Casos de Uso

críticos identificados en la fase de inicio. También debe demostrarse que se han evitado los

riesgos más graves. [KRUCHENTEN, et al., 2000]

Los objetivos de esta fase son:

 Definir, validar y cimentar la arquitectura.

 Completar la visión.

 Crear un plan fiable para la fase de construcción. Este plan puede evolucionar

en sucesivas iteraciones. Debe incluir los costes si procede.

 Demostrar que la arquitectura propuesta soportará la visión con un coste

27
 razonable y en un tiempo razonable.

 Construcción

La finalidad principal de esta fase es alcanzar la capacidad operacional del producto de forma

incremental a través de las sucesivas iteraciones. Durante esta fase todos los componentes,

características y requisitos deben ser implementados, integrados y probados en su totalidad,

obteniendo una versión aceptable del producto. [KRUCHENTEN, et al., 2000]

Los objetivos concretos según incluyen:

 Minimizar los costes de desarrollo mediante la optimización de recursos y

evitando el tener que rehacer un trabajo o incluso desecharlo.

 Conseguir una calidad adecuada tan rápido como sea práctico.

 Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba) tan

rápido como sea práctico.

 Transición

La finalidad de la fase de transición es poner el producto en manos de los usuarios finales, para lo

que se requiere desarrollar nuevas versiones actualizadas del producto, completar la

documentación, entrenar al usuario en el manejo del producto, y en general tareas relacionadas

con el ajuste, configuración, instalación y facilidad de uso del producto. [KRUCHENTEN, et al.,

2000]

Los principales objetivos de esta fase son:

 Conseguir que el usuario se valga por sí mismo.

 Un producto final que cumpla los requisitos esperados, que funcione y satisfaga

suficientemente al usuario.

28
1.8. MODELADO DE APLICACIONES UML

A partir del año 1994, Grady Booch [BOOCH, GRANDY. 1996]. (precursor de Booch '93) y Jim

Rumbaugh (creador de OMT) se unen en una empresa común, Rational Software Corporation, y

comienzan a unificar sus dos métodos. Un año más tarde, en octubre de 1995, aparece UML

(Unified Modeling Language) 0.8, la que se considera como la primera versión del UML. A

finales de ese mismo año, Ivan Jacobson, creador de OOSE (Object Oriented Software Engineer).

UML (Unified Modeling Languaje) es un lenguaje para especificar, construir, visualizar y

documentar los artefactos de un sistema de software orientado a objetos (OO). Un artefacto es

una información que es utilizada o producida mediante un proceso de desarrollo de software.

UML se quiere convertir en un lenguaje estándar con el que sea posible modelar todos los

componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en cuenta un

aspecto importante del modelo, no pretende definir un modelo estándar de desarrollo, sino

únicamente un lenguaje de modelado.

1.9. DIAGRAMAS DE UML

El UML está compuesto por diversos elementos gráficos que se combinan para conformar

diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales

elementos.

La finalidad de los diagramas es presentar diversas perspectivas de un sistema, a las cuales se les

conoce como modelo. Recordemos que un modelo es una representación simplificada de la

realidad; el modelo UML describe lo que supuestamente hará un sistema, pero no dice cómo

implementar dicho sistema.

A continuación se describirán los conceptos y diagramas de UML que se usaron en el presente

proyecto. [GESVIN ROMERO MORENO, 2004]

29
1.9.1. DIAGRAMA DE CLASES

Los diagramas de clases muestran las diferentes clases que componen un sistema y cómo se

relacionan unas con otras. Se dice que los diagramas de clases son diagramas «estáticos» porque

muestran las clases, junto con sus métodos y atributos, así como las relaciones estáticas entre

ellas: qué clases «conocen» a qué otras clases o qué clases «son parte» de otras clases, pero no

muestran los métodos mediante los que se invocan entre ellas.

Una clase define los atributos y los métodos de una serie de objetos. Todos los objetos de esta

clase (instancias de esa clase) tienen el mismo comportamiento y el mismo conjunto de atributos

(cada objetos tiene el suyo propio). En ocasiones se utiliza el término «tipo» en lugar de clase,

pero recuerde que no son lo mismo, y que el término tipo tiene un significado más general.

En, las clases están representadas por rectángulos, con el nombre de la clase, y también pueden

mostrar atributos y operaciones de la clase en otros dos «compartimentos» dentro del rectángulo.

[GESVIN ROMERO MORENO, 2004]

1.9.2. DIAGRAMA DE CASOS DE USO

Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de

casos de uso y los actores participantes en el proceso.

Es importante resaltar que los diagramas de casos de uso no están pensados para representar el

diseño y no puede describir los elementos internos de un sistema. Los diagramas de casos de uso

sirven para facilitar la comunicación con los futuros usuarios del sistema, y con el cliente, y

resultan especialmente útiles para determinar las características necesarias que tendrá el sistema.

En otras palabras, los diagramas de casos de uso describen qué es lo que debe hacer el sistema,

pero no cómo. [GESVIN ROMERO MORENO, 2004]

30
1.9.3. DIAGRAMA DE ESTADOS

Los diagramas de estado muestran los diferentes estados de un objeto durante su vida, y los

estímulos que provocan los cambios de estado en un objeto.

Los diagramas de estado ven a los objetos como máquinas de estado o autómatas finitos que

pueden estar en un conjunto de estados finitos y que pueden cambiar su estado a través de un

estímulo perteneciente a un conjunto finito. [GESVIN ROMERO MORENO, 2004]

1.9.4. DIAGRAMA DE ACTIVIDADES

Los diagramas de actividad describen la secuencia de las actividades en un sistema. Los

diagramas de actividad son una forma especial de los diagramas de estado, que únicamente (o

mayormente) contienen actividades.

Los diagramas de actividad son similares a los diagramas de flujo procesales, con la diferencia de

que todas las actividades están claramente unidas a objetos.

Los diagramas de actividad siempre están asociados a una clase, a una operación o a un caso de

uso.

Los diagramas de actividad soportan actividades tanto secuenciales como paralelas. La ejecución

paralela se representa por medio de iconos de fork/espera, y en el caso de las actividades

paralelas, no importa en qué orden sean invocadas (pueden ser ejecutadas simultáneamente o una

detrás de otra). [GESVIN ROMERO MORENO, 2004]

1.9.5. DIAGRAMA DE COLABORACIÓN

Los diagramas de colaboración muestran las interacciones que ocurren entre los objetos que

participan en una situación determinada. Esta es más o menos la misma información que la

mostrada por los diagramas de secuencia, pero destacando la forma en que las operaciones se

31
producen en el tiempo, mientras que los diagramas de colaboración fijan el interés en las

relaciones entre los objetos y su topología.

En los diagramas de colaboración los mensajes enviados de un objeto a otro se representan

mediante flechas, mostrando el nombre del mensaje, los parámetros y la secuencia del mensaje.

Los diagramas de colaboración están indicados para mostrar una situación o flujo programa

específicos y son unos de los mejores tipos de diagramas para demostrar o explicar rápidamente

un proceso dentro de la lógica del programa. [GESVIN ROMERO MORENO, 2004]

1.9.6. DIAGRAMA DE COMPONENTES

Un diagrama de componentes representa cómo un sistema de software es dividido en

componentes y muestra las dependencias entre estos componentes. Los componentes físicos

incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. Los

diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden

ser usados para modelar y documentar cualquier arquitectura de sistema.

Debido a que los diagramas de componentes son más parecidos a los diagramas de casos de usos,

éstos son utilizados para modelar la vista estática y dinámica de un sistema. Muestra la

organización y las dependencias entre un conjunto de componentes. No es necesario que un

diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada

diagrama describe un apartado del sistema.

En él se situarán librerías, tablas, archivos, ejecutables y documentos que formen parte del

sistema.

Uno de los usos principales es que puede servir para ver qué componentes pueden compartirse

entre sistemas o entre diferentes partes de un sistema. [GESVIN ROMERO MORENO, 2004]

32
1.9.7. DIAGRAMA DE DISTRIBUCIÓN

El diagrama de distribución UML muestra la arquitectura Física de un sistema informático. Puede

representar a los equipos, a los dispositivos y mostrar sus interconexiones y el software que se

encontrará en cada máquina. [GESVIN ROMERO MORENO, 2004]

1.9.8. DIAGRAMA DE PAQUETES

Muestra cómo un sistema está dividido en agrupaciones lógicas mostrando las dependencias entre

esas agrupaciones.

Dado que normalmente un paquete está pensado como un directorio, los diagramas de paquetes

suministran una descomposición de la jerarquía lógica de un sistema.

Los Paquetes están normalmente organizados para maximizar la coherencia interna dentro de

cada paquete y minimizar el acoplamiento externo entre los paquetes. Con estas líneas maestras

sobre la mesa, los paquetes son buenos elementos de gestión. Cada paquete puede asignarse a un

individuo o a un equipo, y las dependencias entre ellos pueden indicar el orden de desarrollo

requerido. [GESVIN ROMERO MORENO, 2004]

1.10. DETERMINACIÓN DE REQUERIMIENTOS

El Objetivo de los requerimientos es identificar y documentar lo que la institución realmente

quiere. Para realizar la determinación de requerimientos, primeramente se debe listar todas las

necesidades que tiene la institución, esto nos sirve como punto de partida para comprender los

requerimientos del sistema, que deben evolucionar por medio del Modelo de Caso de Uso, con el

fin de lograr la especificación final de los requerimientos del sistema.

33
1.11. VORD

El método VORD (ViewPoint - Oriented Requirements Definition) o en español. (Definición de

Requisitos Orientada a Puntos de Vista) [G. KOTANYA y I. SOMMERVILLE, 1996] [G.

KOTANYA et al. 1998] [I. SOMMERVILLE y P. SAWYER, 1997] soporta un modelo de

perspectivas orientado a servicios, Donde cada perspectiva se caracteriza por solicitar una serie

de servicios1.

Entre las aportaciones del método destacan la clasificación de las perspectivas en directas e

indirectas. Las perspectivas directas son aquellas que interactúan directamente con el sistema

(todo tipo de usuarios), mientras que las perspectivas indirectas un interés en algunos o todos los

servicios del sistema, pero no interactúan directamente con él (perspectiva de seguridad,

perspectiva organizativa, etc.) Las perspectivas indirectas son, por lo tanto, las que dictan las

restricciones que afectarán a los servicios de las perspectivas directas.

Un proceso guiado por VORD incluye los siguientes grupos de actividades:

 Identificación de perspectivas: Para ello proponen una serie de guías y una jerarquía

(con herencia) de clases de perspectivas, tanto directas como indirectas, y que puede

extenderse, si es necesario. Esta jerarquía resulta muy útil durante las primeras

aproximaciones a la determinación de las perspectivas.

 Documentación de perspectivas. Consiste básicamente en identificar y especificar, en

cualquier notación, o notaciones, adecuadas, los servicios asociados a cada perspectiva y

las interacciones entre la perspectiva y el futuro sistema, del tipo evento (de la

perspectiva)- respuesta (del sistema). Los requisitos no funcionales imponen

restricciones a los servicios identificados.

1
Obsérvese la diferencia con la orientación a objetos, donde cada objeto es el que provee los servicios
34
  Análisis inter-perspectivas: Tras comprobar la corrección interna de cada perspectiva

se realiza el análisis de conflictos y omisiones. Ambos procesos son, básicamente,

manuales.

Lo destacable de esta propuesta es que proporciona ayuda en la fase de identificación de las

perspectivas. Por otro lado, resulta muy natural, incluso para los usuarios, la descripción de las

perspectivas en términos de servicios.

Otro punto fuerte es que la utilización de un concepto como el de las perspectivas indirectas

resulta de gran ayuda a la hora de determinar los requisitos no funcionales. La mayor limitación

de VORD es que no resulta útil para el tratamiento de interacciones entre distintas perspectivas,

debido a su filosofía orientada a servicios.

El método VORD entra muy poco en la resolución de discrepancias y, extrañamente, parece

considerar exclusivamente las discrepancias entre requisitos no funcionales.

Así, no establece una diferencia entre lo que es inconsistencia (entre descripciones) o lo que es

conflicto (entre perdonas), a consecuencia del tratamiento unidimensional que implícitamente se

da a los contenidos de las perspectivas. De hecho, las perspectivas. De hecho, las perspectivas

que VORD propugna no se orientan a facilitar la exploración de diferentes percepciones

(subjetivas) que puedan existir sobre un futuro sistema y su entorno. Más bien, las perspectivas

describen objetos que existen fuera del sistema y que interactúan con él.

Los autores, con buen criterio, muestran su escepticismo respecto a la posible automatización

tanto de la detección como de la resolución de discrepancias. No obstante, esto no excluye la

necesidad de realizar ambos procesos ni la utilidad e contar con guías para realizarlos, cosa que

VORD o proporciona.

Así, en cuanto a la clasificación de discrepancias, simplemente sugieren realizarla por

prioridades, a partir de la prioridad de los requisitos afectados.

35
Esto tendría como posible ventaja concentrar el esfuerzo en la resolución de las discrepancias

más importantes (o que afecten a los requisitos más prioritarios). No obstante, sigue sin aclararse

cómo, aun siendo manual, podría transcurrir el proceso de generación de resoluciones.

1.12. DESARROLLO DE SOFTWARE PARA LAS APLICACIONES WEB

El diseño y desarrollo de aplicaciones web consiste en implementar sus necesidades, objetivos o

ideas en Internet utilizando las tecnologías más idóneas según su proyecto.

Las aplicaciones web ofrecen servicios a los usuarios de Internet que acceden utilizando un

navegador web como Explorer, Firefox o Safari entre otros, dirigiéndose a una dirección de

Internet donde obtendrán los servicios que buscan.

Las aplicaciones web pueden ser de acceso público como tiendas virtuales, diarios digitales,

portales de Internet o de acceso restringido como son las intranets para mejorar las gestiones

internas de su empresa como el reporte de horas de su personal, gestión de proyectos y tareas,

control de presencia, gestores documentales o el uso de extra nets para aumentar y mejorar el

servicio con sus distribuidores, clientes, proveedores, comerciales y colaboradores externos.

Una de las principales características va a ser su alto grado de interacción con el usuario, y el

diseño de su interfaz debes ser claro, simple y debe estar estructurado de tal manera que sea

orientativo para cada tipo de usuarios.

1.13. METODOLOGÍA DE DESARROLLO WEB

Los principales problemas que nos encontramos es la falta de fiabilidad, seguridad, escalabilidad,

mantenimiento, integración y la alta dependencia para su desarrollo e implantación junto con la

falta de estándares.

36
Se desea controlar procesos creativos de desarrollo con el fin de proporcionar un proceso

sistemático orientado a mejorar la calidad de la aplicación final. Esta disciplina es parte de la base

de las necesidades de evolución, mantenimiento y adaptación a nuevos dispositivos de acceso, la

migración a nuevas plataformas y entornos de desarrollo.

Para todo esto se desarrollada metodologías que permiten estructurar comunicar, entender

simplificar y formalizar tanto el dominio como las decisiones de diseño, así como las decisiones

de diseño, así como disponer de Documentación detallada para posibles cambios del software.

1.14. UWE (UML – BASED WEB ENGINEERING)

UWE (UML - Based Web Engineering) es una herramienta para modelar aplicaciones web,

utilizada en la ingeniería web, prestando especial atención en sistematización y personalización

(sistemas adaptativos).

UWE es una propuesta basada en el proceso unificado y UML[NORA KOCH, ANDREA

KRAUS, ROLF HENNICKER, 2002] pero adaptados a la web. En requisitos separa las fases de

captura, definición y validación. Hace además una clasificación y un tratamiento especial

dependiendo del carácter de cada requisito.

Otras características relevantes del proceso y método de autoría de UWE son el uso de paradigma

orientado a objetos, su orientación al usuario, la definición de una meta-modelo (modelo de

referencia) que da soporte al método y el grado de formalismo que alcanza debido al soporte que

proporciona para la definición de restricciones sobre los modelos.

(Ingeniería Web basada en UML) la aproximación UWE (UML – Based Web Engineering),

presentada por Koch, colegas y extendida en subsecuentes artículos, soporta el desarrollo de

aplicaciones Web con especial énfasis en sistematización, personalización y semi – automática

generación. [NORA KOCH, et al., 2002]

37
 TRAZO
TRAZO

TRAZO

TRAZO TRAZO

TRAZO

Figura 1 – 5: Macro Procesos de la Metodología UWE

Fuente: Process of the Uml - Based Web Engineering Approcach [KOCH2002]

1.14.1. PRINCIPALES ASPECTOS

Los principales aspectos en los que se fundamenta UWE son los siguientes:

 Uso de una notación

Para todos los modelos (UML: Lenguaje de modelado Unificado).

 Definición de métodos

Definición de los pasos para la construcción de los diferentes modelos.

 Especificación de Restricciones

Se recomienda el uso de restricciones escritas (OCL: Lenguaje de restricciones de objetos) para

aumentar la exactitud de los modelos.

38
1.15. MODELO DE ESPACIO DE NAVEGACIÓN

Este modelo indica como el sistema de páginas web del sitio está relacionado internamente. Es

decir cómo se enlazan los elementos de navegación.

Para ello se utilizan unidades de navegación llamadas "nodos" conectadas por enlaces de

navegación. Estos nodos pueden ser mostrados en la misma página web, no tienen por qué estar

en páginas diferentes.

Al mismo tiempo que explicamos este modelo con el ejemplo de la agenda de contactos,

podemos ir viendo los distintos elementos que introduce la metodología UWE, los elementos

introducidos son los siguientes: [NORA KOCH, et al., 2002]

ESTERIO TIPO DEL MODELO DE NAVEGACIÓN

ESTERIO TIPO DESCRIPCIÓN

Clase de Navegación

Menú

Índice

Pregunta

Visita Guiada

Clase de Proceso

Nodo Externo

Tabla 1 – 3: Estereotipos de Modelo de Navegación

Fuente: Process of the Uml - Based Web Engineering Approcach [KOCH2002]

1.16. MODELO DE ESTRUCTURA DE NAVEGACIÓN

El Modelo de estructura de navegación describe como la navegación es soportada por elementos

de acceso. Técnicamente, los caminos de navegación junto con los elementos de acceso son

representados por los modelos de espacio de navegación es dos pasos:

39
 - El primer paso consiste en realzar el modelo de espacio de navegación con índices,

visitas guiadas, y preguntas.

- El segundo consiste en derivar menús directamente del modelo realzado. Los menús

representan posibles elecciones de navegación.

El resultado es un diagrama de clases UML construido con estereotipos UML, los cuales están

definidos según mecanismos de extensión UML. [NORA KOCH, et al., 2002]

1.17. MODELO DE PRESENTACIÓN

El modelo de presentación consiste en un conjunto de vistas que muestran el contenido y la

estructura de los nodos simples, es decir cómo cada nodo es presentado al usuario puede

interactuar con ellos. [NORA KOCH, et al., 2002]

ESTERIO TIPO DEL MODELO DE PRESENTACIÓN

ESTERIO TIPO DESCRIPCIÓN

Grupo de Presentación

Página de Presentación

Texto

Entrada de Texto

Ancla

Carga de Archivos

Botón

Imagen

40
 Formulario

Componente de Cliente

Alternativas de Presentación

Selección

Tabla 1 – 4: Estereotipos de Presentación

Fuente: Process of the Uml - Based Web Engineering Approcach [KOCH2002]

1.18. ESTIMACIÓN DE COSTO DEL SOFTWARE

1.18.1. TÉCNICA DE ESTIMACIÓN

La estimación del costo y del esfuerzo de la elaboración del software nunca será una ciencia

exacta. Son distintas variables que deben tomarse en cuenta como ser: aspectos técnicos, de

entorno e incluso aspectos humanos, pueden afectar el esfuerzo aplicado en el desarrollo de un

proyecto software. Sin embargo la estimación puede dejar de ser un arte obscuro para convertirse

en una serie de pasos sistemáticos que proporcionen estimaciones con un grado de riesgo

aceptable. [ROGER S. PRESSMAN, 1998]

1.18.2. MÉTODO DE LOS PUNTOS DE CASOS DE USO

Este método de estimación de proyectos de software fue desarrollado en 1993 por Gustav Karner

de Rational Software y está basado en una metodología orientada a objetos, dándole el nombre de

“estimación de esfuerzos con casos de uso”. Surgió como una mejora al método de puntos de

función pero basando las estimaciones en el modelo de casos de uso, producto del análisis de

requerimientos. Según su autor, la funcionalidad vista por el usuario (modelo de casos de uso) es

la base para estimar el tamaño del software.

41
Un caso de uso por sí solo no permite efectuar una estimación de esfuerzos ni de tiempos, los

casos de uso son solamente herramientas para el análisis. La idea fundamental es predecir el

tamaño del software a partir de los requerimientos de los casos de uso.

El objetivo fundamental de esta técnica es: Estimar las horas necesarias para ejecutar un conjunto

de casos de uso. Es decir, necesitamos predecir cuánto tiempo llevará el desarrollo de software y

cuántas personas se requieren para realizarlo. Para ello, es necesario cuantificar la complejidad

del sistema y el tiempo necesario para producir una unidad de complejidad. [LIANNY

O’FARILL FDEZ, L. O. F., (n.d.), ESTIMACIÓN DE SOFTWARE BASADA EN PUNTOS DE

CASOS DE USO, EJEMPLO PRÁCTICO, consultado el 14 de Enero 2013, página:

http://www.monografias.com/trabajos87/estimacion-software-basada-puntos.shtml]

A continuación mencionamos algunas de las ventajas y desventajas de este método:

VENTAJAS Y DESVENTAJAS DE LA TÉCNICA DE PUNTOS DE CASOS

DE USO

Ventajas Desventajas

Trabaja bien con diferentes tipos No existe un estándar para escribir casos de

de software uso lo que dificulta la aplicación del

método.

Muestra buen rendimiento en Las herramientas en esta área son caras y

proyectos pequeños, medianos y se enfocan en la evaluación del proyecto.

grandes.

Tabla 1 – 5: Ventajas y Desventajas de la Técnica de Puntos de Casos de Uso

Fuente: http://www.monografias.com

42
Vale la pena aclarar que un caso de uso por sí solo no permite efectuar una estimación de

esfuerzos ni de tiempos, solamente son una herramienta para el análisis. La idea central es

estimar el tamaño (cuantificar) del software a partir de los requerimientos de los casos de uso.

Los pasos para el desarrollo de método de puntos de casos de uso son los siguientes:

1  Calcular los puntos de caso de uso no ajustados

(UUCP)

 Pesar actores (AUW) y pesar casos de uso (UUCW)

 UUCP = AUW + UUCW

2  Calcular los puntos de casos de uso (UCP)

 Pesar Factores Técnicos (TCP)

 Pesar Factores Ambientales (EF)

 UCP = UUCP *TCP * EF

3  Estimar Horas – Hombres

 Horas – Hombres = UCP * 20

Tabla 1 – 6: Pasos para el Método de Puntos de Casos de Uso

Fuente: http://www.monografias.com

1.18.3. FACTOR DE PESO DE LOS ACTORES SIN ACTUAR (UAW)

Consiste en la evaluación de la complejidad de los actores con los que tendrán que interactuar el

sistema. Este puntaje se calcula determinando si cada actor es una persona u otro sistema, además

evalúa la forma en la que este interactúa con el caso de uso y la cantidad de actores de cada tipo.

[LIANNY O’FARILL FDEZ, L. O. F., (n.d.), ESTIMACIÓN DE SOFTWARE BASADA EN

43
PUNTOS DE CASOS DE USO, EJEMPLO PRÁCTICO, consultado el 14 de Enero 2013, página

http://www.monografias.com/trabajos87/estimacion-software-basada-puntos.shtml]

1.18.4. FACTOR DE PESO DE LOS CASOS DE USO SIN AJUSTAR (UAW)

Este punto funciona muy similar al anterior, pero para determinar el nivel de complejidad se

puede realizar mediante dos métodos: basado en transacciones o basado en clases de análisis.

Basado en las transacciones por caso de uso, se toma en cuenta el número de transacciones por

caso de uso y se lo evalúa según la siguiente tabla:

El UUCP son los puntos de casos de uso sin ajustar, esto nos puede servir para tener una idea un

poco más precisa de la dificultad de los casos de uso e interfaces, tomando en cuenta los pesos de

los actores (UAW) y los pesos de los casos de uso (UUCW). [CARMEN GARCIA, JAVIER

GARZAS, C.G y J. G. (n.d.), EL MÉTODO DE LOS PUNTOS CASO DE USO (UCP) página:

http://projectqualitymanagement.files.wordpress.com/2011/05/estimacionpuntoscasouso.pdf]

UUCP = UUCW + UAW

 UUCW = Factor de peso de los actores sin ajustar

 UAW = Factor de peso de los casos de uso sin ajustar

1.18.5. EVALUAR LOS FACTORES DE COMPLEJIDAD TÉCNICA (TCF)

Este se compone de 13 puntos que evalúan la complejidad de los módulos del sistema que se

desarrolla, cada uno de estos factores tienen un peso definido con los cuales se obtendrá puntos

ponderados por cada uno de ellos, según la valoración que se asigne. Para una mejor

comprensión, a continuación se mostrara una tabla con los ítems. [CARMEN GARCIA, JAVIER

44
GARZAS, C.G y J. G. (n.d.), EL MÉTODO DE LOS PUNTOS CASO DE USO (UCP) página:

http://projectqualitymanagement.files.wordpress.com/2011/05/estimacionpuntoscasouso.pdf]

FACTOR DESCRIPCIÓN PESO

TÉCNICO

T1 Sistema Distribuido 2

T2 Rendimiento o Tiempo de respuesta 1

T3 Eficiencia del Usuario Final 1

T4 Procesamiento Interno Complejo 1

T5 El código debe ser Reutilizable 1

T6 Facilidad de Instalación 0.5

T7 Facilidad de Uso 2

T8 Portabilidad 1

T9 Facilidad de Cambio 1

T10 Concurrencia 1

T11 Características especiales de seguridad 1

T12 Provee acceso directo a terceras partes 1

T13 Se requiere facilidades especiales de 1

entrenamiento a usuarios

Tabla 1 – 7: Factores de Complejidad Técnica

Fuente: http://projectqualitymanagement.files.wrodpress.com

45
1.18.6. EVALUAR FACTORES AMBIENTALES (EF)

Los factores sobre los cuales se realiza la evaluación son 8 puntos, que están relacionados con las

habilidades y experiencias de grupo de personas involucradas con el desarrollo del proyecto.

[LIANNY O’FARILL FDEZ, L. O. F., (n.d.), ESTIMACIÓN DE SOFTWARE BASADA EN

PUNTOS DE CASOS DE USO, EJEMPLO PRÁCTICO, consultado el 14 de Enero 2013,

página: http://www.monografias.com/trabajos87/estimacion-software-basada-puntos.shtml]

1.18.7. EL ESFUERZO HORAS - PERSONAS (E)

Este cálculo se realiza con el fin de tener una aproximación del esfuerzo, penado solo en el

desarrollo según las funcionalidades de los casos de uso. [LIANNY O’FARILL FDEZ, L. O. F.,

(n.d.), ESTIMACIÓN DE SOFTWARE BASADA EN PUNTOS DE CASOS DE USO,

EJEMPLO PRÁCTICO, consultado el 14 de Enero 2013, página:

http://www.monografias.com/trabajos87/estimacion-software-basada-puntos.shtml]

1.19. NORMALIZACIÓN DE LA BASE DE DATOS

La tercera forma normal (3NF) es una forma normal usada en la normalización de bases de datos.

La 3NF fue definida originalmente por E.F. Codd en 1971. La definición de Codd. indica que una

tabla está en 3NF si y solo si las dos condiciones siguientes se mantienen:

 La tabla en la segunda forma normal (2NF)

 Ningún atributo no – primario de la tabla es dependiente transitivamente de una clave

primaria.

La base de datos del Proyecto cumplen con la dos condiciones establecidas por lo tanto se

encuentra en tercera forma normal (3NF).

46
1.20. PRUEBAS DE CAJA BLANCA

Las pruebas de caja blanca (también conocidas como pruebas de caja de cristal o pruebas

estructurales) se centran en los detalles procedimentales de software, por lo que su diseño está

fuertemente ligado al código fuente. El testador escoge distintos valores de entrada para examinar

cada uno de los posibles flujos de ejecución del programa y cerciorarse de que se devuelven los

valores de salida adecuados.

Existen varios tipos de pruebas estructurales, como son aquellas que ejercitan todas las

proposiciones del software bajo análisis, las que ejercitan todas las condiciones y las ejercitan los

caminos básicos. La métrica de McCabe ha sido muy popular en el diseño de pruebas. Es un

indicar del número de caminos independientes que existen en un grafo.

1.21. PRUEBA DE CAJA NEGRA

En teoría de sistemas y físicas, se denomina caja negra aquel elemento que es estudiado desde el

punto de vista de las entradas que recibe y las salidas o respuestas que produce, si tener en

cuenta su funcionamiento interno. En otras palabras, de una caja nos interesará su forma de

interactuar con el medio que le rodea, entendiendo qué es lo que hace, pero sin dar importancia a

como lo hace. Por tanto, de un caja negra deben estar muy bien definidas sus entradas y salidas,

es decir, su interfaz; en cambio, no se precisa definir ni conocer os detalles internos de su

funcionamiento.

1.22. MODELOS DE ENCRIPTACION

1.22.1. RSA

[WIKIPEDIA. (5 Junio 2015), RSA. Consultado: 29 de Marzo de 2013]

47
El algoritmo fue descrito en 1977 por Ron Rivest, Adi Shamir y Leonard Adleman, del Instituto

Tecnológico de Massachusetts (MIT); las letras RSA son las iniciales de sus apellidos. Clifford

Cocks, un matemático británico que trabajaba para la agencia de inteligencia británica GCHQ,

había descrito un sistema equivalente en un documento interno en 1973. Debido al elevado coste

de las computadoras necesarias para implementarlo en la época su idea no trascendió. Su

descubrimiento, sin embargo, no fue revelado hasta 1997 ya que era confidencial, por lo que

Rivest, Shamir y Adleman desarrollaron RSA de forma independiente.

El ALGORITMO RSA

El algoritmo consta de tres pasos:

 Generación de claves

1. Cada usuario elige dos números primos distintos y .

 Por motivos de seguridad, estos números deben escogerse de forma aleatoria y

deben tener una longitud en bits parecida. Se pueden hallar primos fácilmente

mediante test de primalidad.

2. Se calcula .

 se usa como el módulo para ambas claves, pública y privada.

3. Se calcula , donde es la función φ de Euler.

4. Se escoge un entero positivo menor que , que sea coprimo con .

 se da a conocer como el exponente de la clave pública.

 Si se escoge un con una suma encadenada corta, el cifrado será más efectivo. Un

exponente muy pequeño (p. ej. ) podría suponer un riesgo para la

seguridad.2

2
Boneh, Dan (1999). «Twenty Years of attacks on the RSA Cryptosystem» (en inglés). Notices of the
American Mathematical Society (AMS) 46 (2): pp. 203–213.
48
 5. Se determina un (mediante aritmética modular) que satisfaga la congruencia

, es decir, que sea el multiplicador modular

inverso de .

 Expresado de otra manera, es dividido exactamente por

 Esto suele calcularse mediante el algoritmo de Euclides extendido.

 se guarda como el exponente de la clave privada.

La clave pública es , esto es, el módulo y el exponente de cifrado. La clave privada

es , esto es, el módulo y el exponente de descifrado, que debe mantenerse en

secreto.

Nota:

 PKCS#1 v2.0 y PKCS#1 v2.1 se especifican mediante la función de Carmichael

en vez de la función de Euler, donde indica

el mínimo común múltiplo.

 Para una mayor eficiencia los siguientes valores se calculan de antemano y se

almacenan como parte de la clave privada:

 y : los primos para la generación de las claves,

 y ,

 .

 Cifrado

Alicia comunica su clave pública a Bob y guarda la clave privada en secreto. Ahora Bob

desea enviar un mensaje a Alicia.

49
Primero, Bob convierte en un número entero menor que mediante un protocolo

reversible acordado de antemano. Luego calcula el texto cifrado mediante la operación

Esto puede hacerse rápido mediante el método de exponenciación binaria. Ahora Bob transmite

a Alicia.

 Descifrado

Alicia puede recuperar a partir de usando su exponente de la clave privada mediante el

siguiente cálculo:

Ahora que tiene en su poder, puede recuperar el mensaje original invirtiendo el padding

scheme.

El procedimiento anterior funciona porque

Esto es así porque, como hemos elegido y de forma que se cumple

La última congruencia se sigue directamente del teorema de Euler cuando es coprimo con .

Puede demostrarse que las ecuaciones se cumplen para todo usando congruencias y el teorema

chino del resto.

Esto muestra que se obtiene el mensaje original:

50
Seguridad

La seguridad del criptosistema RSA está basado en dos problemas matemáticos: el problema de

factorizar números grandes y el problema RSA. El descifrado completo de un texto cifrado con

RSA es computacionalmente intratable, no se ha encontrado un algoritmo eficiente todavía para

ambos problemas. Proveyendo la seguridad contra el descifrado parcial podría requerir la adición

de una seguridad padding scheme.

El problema del RSA se define como la tarea de tomar raíces e-ésimas módulo a componer n:

recuperando un valor m tal que me ≡ c (mod n), donde (e, n) es una clave pública RSA y c es el

texto cifrado con RSA.

La factorización de números grandes por lo general proponen métodos teniendo 663 bits de

longitud usando métodos distribuidos avanzados. Las claves RSA son normalmente de entre

1024-2048 bits de longitud.

1.22.2. MD5

[foro.elhacker.net, (2005, Diciembre 22). Funciones Hash. Consultado: 29 de Marzo de 2013]

En criptografía, MD5 (Algoritmo de Resumen del Mensaje 5) es un algoritmo de reducción

criptográfico de 128 bits ampliamente usado. El código MD5 fue diseñado por Ronald Rivest.

El algoritmo MD5 es una función de cifrado tipo hash que acepta una cadena de texto como

entrada, y devuelve un número de 128 bits. Las ventajas de este tipo de algoritmos son la

imposibilidad (computacional) de reconstruir la cadena original a partir del resultado, y también

la imposibilidad de encontrar dos cadenas de texto que generen el mismo resultado.

Esto nos permite usar el algoritmo para transmitir contraseñas a través de un medio inseguro.

Simplemente se cifra la contraseña, y se envía de forma cifrada. En el punto de destino, para

51
comprobar si el password es correcto, se cifra de la misma manera y se comparan las formas

cifradas.

ALGORITMO MD5

[foro.elhacker.net, (2005, Diciembre 22). Funciones Hash. Consultado: 29 de Marzo de 2013]

El algoritmo MD5 realiza las siguientes operaciones:

1. Adición de Bits de Relleno:

El mensaje es rellenado o ampliado para que su longitud en bits sea congruente a 448 módulo

512. Esto debe ser así puesto que hay que reservar 64 bits para la adición de la longitud del

mensaje en el próximo paso. Así pues, si no se llega a la anterior congruencia, se añadirá el

relleno, consistente en un bit ‘1’ seguido de tantos bits ‘0’ como se precisen.

La razón de porqué un uno seguido de ceros se debe que si se emplea sólo relleno con un valor

(por ejemplo todo ceros) el proceso no sería reversible a la hora de eliminar dicho relleno.

2. Adición de Representación Binaria de Longitud del Mensaje:

Posteriormente se añade al mensaje (con el relleno realizado) una representación de la longitud

del mensaje antes de ser rellenado. Dicha representación tendrá una longitud de 64 bits (16

palabras de 32 bits, es decir, dos enteros de 4 octetos cada uno). En el caso de que el mensaje sea

mayor de bits, sólo se tendrán en cuenta los 64 bits menos representativos, que es lo mismo que

decir que esta representación de la longitud del mensaje está realizada en módulo.

El mensaje tiene ahora un número de bits múltiplo de 512, por lo que habrá un número entero de

palabras de 32 bits (enteros de 4 octetos), concretamente 512 / 32 = 16, de lo que se puede

concluir que si hay b bloques de 512 bits cada uno que forman el mensaje, entonces el mensaje

tendrá n palabras de 32 bits: n = 16 * b.

52
3. Inicializar buffer MD:

Para poder calcular el valor hash o resumen se necesita tener un buffer de 4 palabras de 32 bits

(A, B, C, D), pero antes de comenzar con el proceso se los ha de inicializar con algún valor

determinado, que Rivest establece:

Palabra A = 01 23 45 67 67 45 23 01

Palabra B = 89 ab cd ef ef cd ab 89

Palabra C = fe dc ba 98 98 ba dc fe

Palabra D = 76 54 32 10 10 32 54 76

En la primera columna los valores hexadecimales están ordenados de modo que los valores

menos significativos aparecen en primer lugar (notación empleada por Rivest en la

implementación de este algoritmo), y en la segunda los valores más significativos están a la

izquierda (posiciones más altas de la memoria en Intel 80xxx).

La razón de ver estas formas de representar los mismos valores se debe a intentar evitar

confusiones, pues en función del tipo y arquitectura de la máquina sobre la que ha de trabajar el

algoritmo, este sufrirá adaptaciones en dichos valores al realizar la implementación. Ello es

debido a las distintas formas en que se almacenan los datos en memoria en las distintas

arquitecturas (Intel, Sun, Sparc, ...).

4. Procesar el mensaje en bloques de 512 bits:

Esta es la parte central del algoritmo. Aquí se definen las cuatro funciones que se emplearán en

las cuatro vueltas que se aplicarán sobre cada bloque.

Estas cuatro funciones reciben como parámetros de entrada tres palabras de 32 bits cada una (tres

enteros de 4 bytes de longitud) y devuelven como salida una. Son las siguientes:

F(X, Y, Z) = (X and Y) or ((not X) and Z)

53
 G(X, Y, Z) = (X and Z) or (Y and (not Z))

H(X, Y, Z) = X Y Z

I(X, Y, Z) = Y (X or (not Z))

Dónde:

F Funciona como una sentencia condicional if en programación tradicional: Sí X = 1 entonces Y

será 1 de lo contrario Z será 1.

G También funciona de manera condicional como F: Si Z = 1 entonces X será 1 de lo contrario Y

será 1.

H Simplemente realiza la operación OR-Exclusiva (XOR) de X, Y y Z.

I Realiza la operación XOR con X si es 1 o si Z es 0.

Por otro lado MD5 no utiliza las constantes (‘magic’ constants) que se empleaban en MD4. En su

lugar se emplea una tabla de 64 elementos construida a partir de la función trigonométrica seno.

Sea T el elemento i-ésimo de dicha tabla, que será igual a la parte entera de 4294967296 veces

abs (sen(i)), donde i está expresada en radianes. Puesto que hay que realizar 16 pasos en cada una

de las cuatro vueltas, es decir, 64 operaciones, la idea es usar una constante de la anterior tabla

para cada vuelta.

5. Recoger el valor hash de salida:

El valor hash de salida se obtiene de los registros A, B, C y D donde el octeto más representativo

es D y el que menos A. Independientemente de la longitud del mensaje, su tamaño será de 128

bits.

¿QUE ES UN HASH?

Una función hash es un algoritmo matemático que nos da un resultado B al aplicarlo a un valor

inicial A. Es como cualquier función matemática, por ejemplo la función raíz cuadrada nos daría

54
como resultado 2 si se la aplicamos al número 4. E igual que cualquier función matemática tiene

que actuar de tal forma y tiene que cumplir con ciertos criterios. No nos puede devolver cualquier

cosa, lo que nos devuelva requiere que tenga ciertas propiedades para que podamos usarlo.

¿QUE PROPIEDADES TIENEN QUE CUMPLIR LAS FUNCIONES HASH?

1. Sea cual sea la longitud del texto base A, la longitud de su hash resultante B siempre va a

ser la misma. Por ejemplo, si la longitud de la salida B esta definida en 128 bits, si aplicamos una

función hash a un A de 5 bits nos dará un B de 128 bits, y si se la aplicamos a un A de 380

millones de bits, nos dará un B de 128 bits igualmente.

2. Para cada entrada A, la función generará una salida B única. O lo que es lo mismo, es

imposible que dos textos bases A y A' tengan un mismo hash B.

Según estas dos primeras propiedades, nos damos cuenta enseguida de la utilidad de las funciones

de hash.

3. Dado un texto base, es fácil y rápido (para un ordenador) calcular su número resumen.

4. Es imposible reconstruir el texto base a partir del número resumen.

Esto es lo que se conoce como One-Way hash functions. A partir del hash es imposible

reconstruir el texto base.

Este es un punto que muchos no tiene muy claro. Solo hay que leer bien, a partir del hash B es

imposible sacar el texto A, quiere decir no existe forma o es computacionalmente imposible, que

mediante operaciones matemáticas inversas o no a las del algoritmo de hash, se llegue desde B al

texto base.

55
Esto es muy distinto que usar fuerza bruta. No tiene nada que ver. Con fuerza bruta le aplicamos

la función de hash a diferentes textos hasta que obtenemos un hash similar al hash del texto que

buscamos, con lo que por consecuencia tendremos el texto buscado.

APLICACIONES

Los resúmenes MD5 se utilizan extensamente en el mundo del software para proporcionar la

seguridad de que un archivo descargado de Internet no se ha alterado. Comparando una suma

MD5 publicada con la suma de comprobación del archivo descargado, un usuario puede tener la

confianza suficiente de que el archivo es igual que el publicado por los desarrolladores. Esto

protege al usuario contra los 'Caballos de Troya' o 'Troyanos' y virus que algún otro usuario

malicioso pudiera incluir en el software.

La comprobación de un archivo descargado contra su suma MD5 no detecta solamente los

archivos alterados de una manera maliciosa, también reconoce una descarga corrupta o

incompleta.

Para comprobar la integridad de un archivo descargado de Internet se puede utilizar una

herramienta MD5 para comparar la suma MD5 de dicho archivo con un archivo MD5SUM con el

resumen MD5 del primer archivo. En los sistemas UNIX, el comando de md5sum es un ejemplo

de tal herramienta. Además, también está implementado en el lenguaje de scripting PHP como

MD5 ("") entre otros.

En sistemas UNIX y GNU/Linux se utiliza el algoritmo MD5 para calcular el hash de las claves

de los usuarios.

En el disco se guarda el resultado del MD5 de la clave que se introduce al dar de alta un usuario,

y cuando éste quiere entrar en el sistema se compara el hash MD5 de la clave introducida con el

hash que hay guardado en el disco duro. Si coinciden, es la misma clave y el usuario será

56
autenticado. Los sistemas actuales GNU/Linux utilizan funciones de hash más seguras, como

pueden ser SHA-2 o SHA-3.

El MD5 también se puede usar para comprobar que los correos electrónicos no han sido alterados

usando claves públicas y privadas.

1.22.3 QR

[WIKIPEDIA. (9 Junio 2015), QR. Consultado: 30 de abril de 2013]

Un código QR (quick response code, «código de respuesta rápida») es un módulo útil para

almacenar información en una matriz de puntos o un código de barras bidimensional creado en

1994 por la compañía japonesa Denso Wave, subsidiaria de Toyota. Se caracteriza por los tres

cuadrados que se encuentran en las esquinas y que permiten detectar la posición del código al

lector. La sigla «QR» viene de la frase inglesa «Quick Response» («Respuesta Rápida» en

español), pues los creadores (un equipo de dos personas en Denso Wave, dirigido por Masahiro

Hara)3 tenían como objetivo que el código permitiera que su contenido se leyera a alta velocidad.

CARACTERISTICAS GENERALES

Aunque inicialmente se usó para registrar repuestos en el área de la fabricación de vehículos, hoy

los códigos QR se usan para administración de inventarios en una gran variedad de industrias. La

inclusión de software que lee códigos QR en teléfonos móviles, ha permitido nuevos usos

orientados al consumidor, que se manifiestan en comodidades como el dejar de tener que

introducir datos de forma manual en los teléfonos. Las direcciones y los URL’s se están

volviendo cada vez más comunes en revistas y anuncios. El agregado de códigos QR en tarjetas

3
Historia de los códigos QR en la página oficial de Denso Wave.
57
de presentación también se está haciendo común, simplificando en gran medida la tarea de

introducir detalles individuales de un nuevo cliente en la agenda de un teléfono móvil.

Los códigos QR también pueden leerse desde PC, smartphone o tableta mediante dispositivos de

captura de imagen, como puede ser un escáner o la cámara de fotos, programas que lean los datos

QR y una conexión a Internet para las direcciones web.

Respecto a los datos que puede manejar, te interesará saber que pueden contener hasta 4.200

caracteres alfanuméricos, es decir, letras, números y caracteres.

El estándar japonés para códigos QR (JIS X 0510) fue publicado en enero de 1998 y su

correspondiente estándar internacional ISO (ISO/IEC18004) fue aprobado en junio de 2000.

Un detalle importante sobre el código QR es que, a diferencia de otros formatos de códigos de

barras bidimensionales como el BIDI, su código es abierto y sus derechos de patente (propiedad

de Denso Wave) no son ejercidos.

¿QUÉ TIPO DE INFORMACIÓN PUEDE ALMACENARSE EN LOS CÓDIGOS QR?

Información de contacto (vCard). Nombre, compañía, teléfono, dirección postal...Una dirección

web (URL). Por ejemplo al blog, a la web o incluso a tu perfil en Facebook, Twitter, Linkld,

Youtube, una dirección de email, un mensaje del tipo SMS, un número de teléfono para realizar

una llamada, parámetros de acceso a una red Wifi, datos de un evento para un calendario (día y

hora de comienzo/fin, nombre del evento...), una Geolocalización para verla en un mapa.

[computerhoy.com, (2014, Junio 29). ¿Qué son los códigos QR y cómo funcionan? Consultado:

22 de Agosto de 2014]

58
PRECAUCIÓN CON LOS CÓDIGOS QR

La ventaja de los códigos QR es el acceso directo e inmediato a la información a la que hacen

referencia. Sin embargo, por esto mismo, también son peligrosos ya que su inmediatez puede ser

aprovechada para enviarnos a un sitio web infectado con virus o para la instalación de programas

maliciosos en el dispositivo.

Es recomendable escanear códigos QR de sitios de confianza y elegir aplicaciones de lectura de

QR que permitan la visualización previa de la dirección web a la que dirigen.

[computerhoy.com, (2014, Junio 29). ¿Qué son los códigos QR y cómo funcionan? Consultado:

22 de Agosto de 2014]

59