escuela superior de ingenierÍa mecÁnica y electrica …

INSTITUTO POLITÉCNICO NACIONAL

ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELECTRICA

UNIDAD CULHUACAN

TESINA

Seminario de Titulación:

“Las tecnologías aplicadas a las redes de computadoras” FNS 5092005/04/2008

DEADMINIS

SARROLLO DE UNA APLICACIÓN TRATIVA IMPLEMENTADA EN UNA VPN.

Que como prueba escrita de su Examen Profesional para obtener

el Título de:

Ingeniero en Comunicaciones y Electrónica. JUAN CARLOS VÁZQUEZ AMAYA.

Ingeniero en Computación. GERARDO ADALID ALTAMIRANO NUÑEZ.

ANAMELI JARA HERNÁNDEZ.

Ingeniero en Informática. IRIS VICTORIA VERA HERNÁNDEZ.

México D.F., Agosto 2008.

INSTITUTO POLITÉCNICO NACIONAL ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA ELÉCTRICA

UNIDAD CULHUACAN TESINA

POR LA OPCIÓN DE SEMINARIO DE TITULACIÓN

FNS5092005/04/2008 QUE PARA OBTENER EL TÍTULO DE INGENIERO EN COMUNICACIONES Y

ELECTRÓNICA PRESENTA: VÁZQUEZ AMAYA JUAN CARLOS QUE PARA OBTENER EL TÍTULO DE INGENIERO EN COMPUTACIÓN PRESENTAN: ALTAMIRANO NUÑEZ GERARDO ADALID

JARA HERNÁNDEZ ANAMELI QUE PARA OBTENER EL TÍTULO DE INGENIERO EN INFORMÁTICA PRESENTA: VERA HERNÁNDEZ IRIS VICTORIA

DESARROLLO DE UNA APLICACIÓN ADMINISTRATIVA IMPLEMENTADA EN UNA VPN SUGIERE REALIZAR UNA APLICACIÓN DE SOFTWARE QUE SEA CAPAZ DE APLICAR EXAMENES ESCOLARES Y CORPORATIVOS UTILIZANDO COMO MEDIO LA INTERNET. CONSIDERANDO LAS CAPAS DE LA INGENIERÍA DE SOFTWARE COMO UN EJE FUNDAMENTAL EN EL DESARROLLO DEL SISTEMA.

CAPITULADO

INTRODUCCIÓN. CAPÍTULO 1 PROCESO DE DESARROLLO DE SOFTWARE. CAPÍTULO 2 ETAPAS DEL PROCESO DE SOFTWARE. CAPÍTULO 3 ANÁLISIS, DISEÑO, IMPLEMANTACIÓN DE LA APLICACIÓN SUGERIDA. CAPÍTULO 4 IMPLEMENTACIÓN DE LA APLICACIÓN EN UNA RED PRIVADA VIRTUAL (VPN). CONCLUSIONES. BIBLIOGRAFÍA. GLOSARIO.

México D.F. 09 de Agosto de 2008

M. en C. Diana Salomé Vázquez Estrada Coordinador Académico del Seminario

Ing. Patricia Cortés Pineda. Asesor.

M. en C. Héctor Becerril Mendoza Jefe del Departamento de Ingeniería

en Comunicaciones y Electrónica

1

Agradecimientos.

A Dios por permitirme realizar un logro de valiosa importancia en mi vida. A mis padres y hermanas que con su enseñanza de valores y principios me he conducido por el camino correcto. Gracias por estar conmigo. A mi esposa Lorena por impulsar día con día mi superación y apoyarme incondicionalmente en el logro de este trabajo, gracias por lograr que mi corazón viva intensamente. Te amo. A mis hijas Samantha y Andrea que han logrado completar mi sueño, a ustedes que están llenas de bendiciones agradezco tanta felicidad que me han brindado. Con mucha ilusión espero la llegada de mi bebé, gracias a Dios por tener esta familia, los amo. A la gente que siempre creyó en mi y me impulso para seguir con la mirada en mis anhelos. A todos mis amigos, compañeros y directores de tesis por brindarme la oportunidad de aprender de ellos.

Juan Carlos. Quiero extenderles mi mayor agradecimiento a Guillermina y Jorge, por ese respaldo que siempre tuve de parte de ustedes, por toda la libertad que me dieron para definir el camino que debía tomar, por todo ese apoyo que me brindaron cuando cometí errores. Esto es la culminación de un objetivo más en mi vida, que gracias a la educación que me dieron he podido sacar adelante. Muchas gracias por ser mis padres. Los quiero mucho. A ti que eres el motor de mi vida, que me apoyaste en los momentos mas difíciles, tu que has comprendido que todo esto es por ti y para ti. A ti que has colaborado de manera excepcional para lograr este triunfo más. A ti que eres mi vida: Gracias. Te Amo Lili. A Bere, Jorge y Daniel mis queridos hermanos, gracias por estar conmigo, por ese apoyo incondicional que siempre he tenido de parte suya, espero que esta parte tan importante de mi vida, los motive a cumplir todas sus metas y sean siempre mejores personas en todos los aspectos. Los adoro hermanos. Danna, desde que llegaste este mundo has iluminado de manera increíble mi corazón y mi vida, todo lo que he hecho, lo que hago y lo que haga en el futuro, es para ti. Te amo mi bebe hermoso. Así mismo quiero agradecer a todas las personas que estuvieron presentes durante mi formación académica: profesores, amigos, compañeros de escuela, ya que de alguna manera colaboraron para formar a este Ingeniero, en verdad muchas gracias.

Gerardo Adalid.

2

Agradezco a Dios por llenar mi vida de bendiciones y guiarme hasta encontrarme en estos momentos tan importantes de mi vida y lograr otra meta más en mi vida. A mi madre por el ejemplo de superación que ha mostrado, por el sacrificio que ha realizado en gran parte de su vida para formarme y educarme, por la confianza que deposita en mí para forjar uno de mis más grandes anhelos de la que dependerá mi vida, que es mi carrera profesional. A mis hermanas y hermano quienes a pesar de tener puntos de vista diferentes a los míos, han apoyado y comprendido mis decisiones y por su compañía en los momentos que más los necesito. Los quiero. A la persona que en este momento ocupa un gran espacio en mi corazón, a quien amo y considero parte de mi vida en mi presente y mi futuro. Agradezco a mis mejores amigos los cuales me han brindado confianza y lealtad con los que comparto tantas aventuras, experiencias y triunfos, a mis compañeros de equipo de tesis que pasan a ser parte de mis mejores amigos.

Anameli. Agradezco: A mi familia por brindarme un hogar cálido, enseñarme que la perseverancia y el esfuerzo son el camino para lograr objetivos y poder llegar hasta este logro, que no hubiese podido ser realidad sin ustedes, gracias por darme la posibilidad de que de mi boca salga esa palabra…FAMILIA. A Ciria, Carlos, Jorge y Moisés mis hermanos de experiencias, quienes tuvieron la paciencia suficiente para apoyarme, gracias por enseñarme que no hay limites, que lo que me proponga lo puedo lograr. A mi equipo de tesis, por ser el último escalón para poder alcanzar este sueño, MI SUEÑO, que ahora es una realidad.

Iris Victoria.

3

Índice.

Capítulo I.- Proceso de desarrollo de software. 1 1.1 Introducción. 1 1.2 Ingeniería de software. 2 1.3 El proceso de desarrollo del software. 4 1.4 Modelos de proceso de software. 7 1.4.1 Codificar y corregir. 8 1.4.2 Modelo en cascada. 8 1.4.3 Desarrollo evolutivo. 10 1.4.4 Desarrollo formal de sistemas. 12 1.4.5 Desarrollo basado en reutilización. 13 1.4.6 Procesos iterativos. 14 1.4.6.1 Desarrollo incremental. 14 1.4.6.2 Desarrollo en espiral. 15 1.5 Metodologías para desarrollo de software. 18 1.5.1 Metodologías estructuradas. 19 1.5.2 Metodologías orientadas a objetos. 19 1.5.3 Metodologías ágiles. 20 1.5.4 Metodologías tradicionales o no ágiles. 20 1.6 Seguridad en redes. 20 1.6.1 Dimensión del valor de los datos. 22 1.6.2 Definiendo seguridad en redes. 22 Capítulo II.- Etapas del proceso de software. 24 2.1 Introducción. 24 2.2 Etapas en el método CASE. 25 2.2.1. Estrategia. 26 2.2.2 Análisis 27 2.2.3 Diseño. 28 2.2.3.1 Construcción 29 2.2.3.2 Documentación 30 2.2.4 Transición 30 2.2.5 Producción 31 2.3 Modelado de software. 32 2.3.1 UML. 32 2.3.2 Herramientas de UML 33 2.3.2.1 Diagrama de casos de uso. 33 2.3.2.2 Diagrama de Clases. 34 2.3.2.3 Diagramas de estados. 35 2.3.4.4 Diagramas de actividad. 35 2.3.4.5 Diagramas de componentes. 35 2.3.2.6 Diagramas de secuencias. 35 2.3.2.7 Diagramas de colaboración. 36 2.3.2.8 Diagrama de objetos. 37

4

2.4 Programación orientada a objetos. 37 2.4.1 Definición. 37 2.4.2 Objetos. 38 2.4.3 Encapsulamiento y ocultación. 38 2.4.4 Clases. 39 2.4.5 Mensajes (activación de objetos). 39 2.4.6 Herencia. 40 2.4.7 Polimorfismo. 40 2.5 Análisis. 41 2.5.1 Definición de una arquitectura candidata. 42 2.5.1.1 Especificación de requerimientos en el software ERS. 42 2.5.1.2 Visión del sistema. 43 2.5.1.3 Glosario del sistema. 43 2.5.1.4 Registro de riesgo. 43 2.5.1.5 Modelo de análisis. 44 2.5.1.6 Modelo de diseño. 44 2.5.1.7 Modelo de implantación. 44 2.5.1.8 Documento de una arquitectura de software. 44 2.5.2 Análisis del comportamiento del sistema. 45 2.5.2.1 Modelo de servicios. 45 2.5.2.2 Mapa de navegación. 45 2.5.2.3 Prototipo de la interfaz de usuario. 46 2.5.2.4 Registro de evaluación. 46 2.6 Diseño. 47 2.6.1 Diseño de los servicios. 48 2.6.2 Diseño de los componentes. 48 2.6.3 Refinado de la arquitectura. 49 2.7 Arquitectura de software. 49 2.7.1 Tipos de arquitectura de software. 50 2.7.2 Documentación. 51 2.7.3 Patrones arquitectónicos. 51 2.7.4 Definición de vistas. 52 2.8 Implementación 53 2.8.1 Diseño de las bases de datos. 54 2.8.1.1 Cualidades de un buen diseño de bases de datos. 56 2.8.1.2 El modelo relacional. 57 2.8.1.2.1 Estructura del modelo relacional. 57 2.8.1.2.2 Transformación de relaciones 1:1. 58 2.8.1.2.3 Transformación de relaciones 1:N. 59 2.8.1.2.4 Transformación de relaciones N:N. 59 2.8.1.3 Modelo Entidad/Interrelación (E/R). 59 2.8.1.3.1 Proceso de diseño en el modelo E-R. 60 2.8.1.4 Normalización 60 2.8.1.4.1 Grados de normalización. 62 2.8.2 Codificación del software. 63 2.8.3 Pruebas. 65 2.8.3.1 Prueba de caja blanca. 66

5

2.8.3.2 Prueba de caja negra. 67 2.8.4 Mantenimiento. 68 2.8.4.1 Mantenibilidad. 69 2.8.4.2 Reingeniería del software. 69 Capítulo III.- Análisis, diseño e implementación de la aplicación sugerida. 72 3.1 Análisis. 73 3.2 Diseño. 75 3.2.1 Descripción general de interfaces. 75 3.2.1.1 Interfaces del sistema. 75 3.2.1.2 Interfaz de usuario y patrones arquitectónicos. 76 3.2.1.3 Interfaces de comunicación. 76 3.2.1.4 Interfaces de hardware. 76 3.2.1.5 Interfaces del software. 76 3.3 Modelo. 77 3.4 Metodología. 77 3.5 Modelado. 77 3.6 Programación. 79 3.6.1 Base de datos. 80 Capítulo IV.- Implementación de la aplicación en una red virtual privada (VPN). 82 4.1 Definición VPN. 82 4.2 Ventajas de una VPN. 83 4.3 Requerimientos básicos de las VPN. 85 4.4 Tipos de VPN. 86 4.4.1 Diferentes tecnologías para armar VPN’s. 87 4.4.1.1 IPSEC (Internet Protocol Secure). 87 4.4.1.2 PPTP (Point to Point Tunneling Protocol). 87 4.5 Diagramas. 88 4.5.1 Diagrama de cliente a servidor. 89 4.5.2 De cliente a red interna LAN. 89 4.5.3 De red interna a red interna (LAN a LAN). 89 4.6 Requerimientos para el armado de una VPN. 90 4.7 Instalación y configuración de pptp en Linux. 91 4.7.1 Archivo pptpd.conf. 92 4.7.2 Archivo /etc/ppp/pptpd-options. 93 4.7.3 Archivo /etc/ppp/chap-secrets. 94 4.7.4 Depurando errores. 95 4.7.5 Configuración de los clientes pptp. 95 Conclusiones. 96 Bibliografía. 97 Glosario. 99

6

Índice de figuras.

Capítulo I.- Proceso de desarrollo de software. Figura 1.1 Capas de la Ingeniería de Software 3 Figura 1.2 Proceso de desarrollo de software. 4 Figura 1.1 Elementos del proceso del software. 6 Figura 1.4 Relación entre elementos del proceso del software. 6 Figura 1.2 Modelo de desarrollo en cascada. 9 Figura 1.6 Modelo de desarrollo evolutivo. 10 Figura 1.7 Paradigma de programación automática. 12 Figura 1.8 Desarrollo basado en reutilización de componentes. 13 Figura 1.9 Modelo de desarrollo iterativo incremental. 15 Figura 1.10 Modelo de desarrollo en espiral. 17 Capítulo II.- Etapas del proceso de software. Figura 2.1 Etapas del método CASE. 26 Figura 2.2 Etapa de estrategia. 27 Figura 2.3 Etapa de análisis. 28 Figura 2.4 Etapa de diseño. 29 Figura 2.5 Etapa de construcción. 29 Figura 2.6 Etapa de documentación. 30 Figura 2.7 Etapa de transición. 31 Figura 2.8 Etapa de producción. 31 Figura 2.9 Clasificación de diagramas de UML. 33 Figura 2.10 Ejemplo de actor y caso de uso. 34 Figura 2.11 Ejemplo de una clase. 34 Figura 2.12 Ejemplo de diagramas de secuencia. 36 Figura 2.13 Ejemplo de diagramas de colaboración (para su entendimiento). 36 Figura 2.14 Ejemplo de diagramas de objetos. 37 Figura 2.15 Diagramas de análisis y diseño de un desarrollo de software. 42 Figura 2.16 Definiendo una arquitectura candidata. 45 Figura 2.17 Analizar el comportamiento del sistema. 46 Figura 2.18 Diseño los servicios. 48 Figura 2.19 Diseño de los componentes. 49 Figura 2.20 Tabla de una base de datos. 54 Capítulo III.- Análisis, diseño e implementación de la aplicación sugerida. Figura 3.1 Diagrama de caso de uso y de administración de usuarios. 78 Figura 3.2 Diagrama de estados. 78 Figura 3.3 Diagrama de colaboración. 79

7

Capítulo IV.- Implementación de la aplicación en una red virtual privada (VPN). Figura 4.1 Diagrama lógico. 83 Figura 4.2 Diagrama de cliente / servidor. 89 Figura 4.3 Diagrama de cliente a red interna. 89 Figura 4.4 Diagrama de red interna a red interna (LAN a LAN). 90

Índice de tablas.

Tabla 1.1 Comparación entre modelos de proceso de software. 18 Tabla 2.1 Funcionalidad del modelo de análisis. 41 Tabla 2.2 Tipos de relaciones. 60 Tabla 2.3 Formas de normalización. 62

8

Justificación.

Dada la necesidad que tienen las organizaciones de agilizar y evaluar procesos

administrativos en diferentes puntos geográficos, se brindarán las herramientas necesarias

de software; a través del desarrollo de una aplicación y se implementará en una red virtual

privada VPN garantizando que el flujo de la información cumpla con medidas de seguridad

de estándares de calidad.

Introducción. A lo largo del último siglo, la tecnología, entendida como el conjunto de actividades y

conocimientos científicos y técnicos empleados por el ser humano para la construcción o

elaboración de objetos, sistemas o entornos, con el objetivo de resolver problemas y

satisfacer necesidades, individuales o colectivas, ha ido adquiriendo una importancia

progresiva en la vida de las personas y en el funcionamiento de la sociedad. La formación

requiere actualmente una atención específica a la adquisición de los conocimientos

necesarios para tomar decisiones sobre el uso de objetos y procesos tecnológicos, resolver

problemas relacionados con ellos utilizar los distintos materiales, procesos y objetos

tecnológicos para aumentar la capacidad de actuar sobre el entorno y para mejorar la

calidad de vida.

Sugerimos desarrollar un sistema de información administrativo, basándose en una

arquitectura y modelado de software implementándolo en una red virtual privada VPN.

Se propondrá un sistema de seguridad que garantice la integridad de los datos, debido a la

vulnerabilidad constante que sufren los sistemas de información instalados en la mayoría

de las empresas.

Hoy en día las redes se han convertido en un factor crítico para cualquier organización.

Cada vez en mayor medida, las redes transmiten información vital.

9

Se ha demostrado en la actualidad que las redes reducen en tiempo y dinero los gastos de

las empresas, eso ha significado una gran ventaja para las organizaciones sobre todo las que

cuentas con oficinas remotas a varios kilómetros de distancia, pero también es cierto que

estas redes remotas han despertado la curiosidad de algunas personas que se dedican a

atacar los servidores y las redes para obtener información confidencial, por lo tanto dichas

redes deberán cumplir con atributos tales como seguridad, fiabilidad, alcance geográfico y

efectividad en costos.

Como consecuencia es de vital importancia la seguridad de las redes, por eso escuchamos

hablar tanto de los famosos cortafuegos (firewalls) y las redes privadas virtuales (VPN).

Éstas últimas muy óptimas debido a que los costos son bajos porque utilizan la

infraestructura de redes públicas, además de tener la posibilidad de que los datos viajen

encriptados, seguros, con una buena calidad y velocidad.

10

Capítulo I.- Proceso de desarrollo de software.

1.1 Introducción.

Un sistema informático está compuesto por hardware y software. En cuanto al hardware, su

producción se realiza sistemáticamente y la base de conocimiento para el desarrollo de

dicha actividad está claramente definida. La fiabilidad del hardware es, en principio,

equiparable a la de cualquier otra máquina construida por el hombre, sin embargo, respecto

del software su construcción y resultados han sido históricamente cuestionados debido a los

problemas asociados, entre ellos podemos destacar los siguientes:

• Los sistemas no responden a las expectativas de los usuarios.

• Los programas fallan con cierta frecuencia.

• Los costos del software son difíciles de prever y normalmente superan las estimaciones.

• La modificación del software es una tarea difícil y costosa.

• El software se suele presentar fuera del plazo establecido y con menos prestaciones de

las consideradas inicialmente.

• Normalmente, es difícil cambiar de entorno de hardware usando el mismo software.

• El aprovechamiento óptimo de los recursos (personas, tiempo, dinero, herramientas, etc.)

no suele cumplirse.

En base al estudio que realizó el Centro Experimental de Ingeniería de Software (CEIS) en

1996, sólo un 16% de los proyectos de software son exitosos es decir, terminan dentro de

plazos y costos y cumplen los requerimientos acordados. Otro 53% sobrepasa costos y

plazos y cumple parcialmente los requerimientos. El resto ni siquiera llega al término.

Algunas deficiencias comunes en el desarrollo de software son:

• Escasa o tardía validación con el cliente.

11

• Inadecuada gestión de los requisitos.

• No existe medición del proceso ni registro de datos históricos.

• Estimaciones imprevistas de plazos y costos.

• Excesiva e irracional presión en los plazos.

• Escaso o deficiente control en el progreso del proceso de desarrollo.

• No se hace gestión de riesgos formalmente.

• No se realiza un proceso formal de pruebas.

• No se realizan revisiones técnicas formales e inspecciones de código.

Por lo anterior para que la producción de software sea fiable y funcione eficientemente

sobre máquinas reales debemos considerar los siguientes puntos:

• Los principios robustos de la ingeniería aplicables al desarrollo de software de

computadora.

• Construir el software económicamente.

• Crear programas de computadora que funcionen eficientemente no en una máquina sino

en diferentes máquinas reales.

Sin embargo, dicho planteamiento además deberá incluir otros aspectos, tales como: mejora

de la calidad del software, satisfacción del cliente, mediciones y métricas, etc.

1.2 Ingeniería de software.

Para desarrollar software de gran calidad debemos considerar lo que la IEEE1 ha definido

como la Ingeniería de Software: la aplicación de un enfoque sistemático, disciplinado y

cuantificable para el desarrollo, operación y mantenimiento del software.

Esta disciplina se conoce como una tecnología multicapa, la cual se ilustra en la figura 1.1.

1 Institute of Electrical and Electronics Engineers

Un enfoque de calidadProcesoMétodos

Herramientas

Un enfoque de calidadProcesoMétodos

Herramientas

12

Figura 3.1 Capas de la Ingeniería de Software.

Como es visible en la figura cada una de las capas descansa sobre la capa anterior, para

tener un mayor detalle de estas se explican a continuación:

• Un enfoque de calidad: donde cualquier disciplina de ingeniería debe descansar sobre un

esfuerzo de organización de calidad, la gestión total de esta y las filosofías similares

fomentan una cultura continua de mejoras de procesos que conduce al desarrollo de

enfoques cada vez más robustos.

• Capa de proceso: es la capa fundamental de esta disciplina, la cual define un marco de

trabajo para un conjunto de áreas clave, que forman la base del control de gestión de

proyectos de software y establece el contexto en donde se aplican los métodos

técnicos, es donde se producen los resultados de trabajo, se establecen controles, se

asegura la calidad y el cambio se gestiona adecuadamente.

• Los métodos: indican cómo construir técnicamente el software, abarcan una gama de

tareas que incluyen el análisis de requisitos, diseño, construcción de programas,

pruebas y mantenimiento. Dependen de un conjunto de principios básicos que

gobiernan cada área de la tecnología e incluyen actividades de modelado y otras

técnicas descriptivas.

• Las herramientas: proporcionan un soporte automático o semi-automático para el

proceso y los métodos, a éstas se les llama herramientas CASE2.

2 CASE: Ver Glosario

13

Dado lo anterior, el objetivo primordial es lograr productos de calidad, tanto en su forma

final como durante su elaboración, mediante un proceso apoyado por métodos y

herramientas.

1.3 El proceso de desarrollo del software.

Este proceso tiene como propósito la producción eficaz y eficiente de un producto que

reúna los requisitos del cliente, como se muestra en la figura 1.2.

Dada la dificultad por controlar variables externas durante el proceso de desarrollo después

de entregado el producto, se dificulta la definición de la aplicación y sus requisitos, sobre

todo cuando no se tiene precedentes en productos de software similares, esto hace que los

requisitos sean difíciles de consolidar tempranamente, así, los cambios en los necesidades

son inevitables, no sólo después de entregado en producto sino también durante el proceso

de desarrollo.

Requisitos nuevoso modificados

Sistema nuevoo modificado

Proceso de Desarrollo de Software










Figura 1.4 Proceso de desarrollo de software.

No existe un proceso universal que sea efectivo para todos los contextos de proyectos de

desarrollo, debido a esta diversidad, es difícil automatizar todo el proceso de desarrollo de

software.

A pesar de la variedad de propuestas de proceso de software, existe un conjunto de

actividades fundamentales que se encuentran presentes en todos ellos:

• Especificación: se debe definir la funcionalidad y restricciones operacionales que debe

cumplir el software.

• Diseño e implementación: se diseña y construye el software de acuerdo a la

especificación.

14

• Validación: el software debe considerar todas las situaciones posibles en la generación

de información, para asegurar que cumpla con lo que quiere el cliente.

• Evolución: para adaptarse a las necesidades del cliente presentes y futuras.

Además de estas actividades fundamentales, se pueden considerar un conjunto de acciones

protectoras, mismas que se aplican a lo largo de todo el proceso del software:

• Seguimiento y control de proyecto.

• Revisiones técnicas formales.

• Garantía de calidad del software.

• Gestión de configuración del software.

• Preparación y producción de documentos.

• Gestión de reutilización.

• Mediciones.

• Gestión de riesgos.

Elementos que debemos considerar para caracterizar un proceso de desarrollo de software

son mostrados en la figura 1.3 y a continuación se detallan:

• Un marco de trabajo de proceso común: implica definir un pequeño número de

actividades que son aplicables a todos los proyectos de software, con independencia

del tamaño o complejidad.

• Un conjunto de tareas: cada una a su vez, es una colección de tareas, controles de

proyectos, entregas y puntos de garantía de calidad, que permiten que las actividades

del marco de trabajo se adapten a las características y los requisitos del equipo del

proyecto.

Marco de trabajo del proceso común

Actividades de trabajo del proceso común

Conjunto de tareas

Actividades de protección

Tareas

15Hitos, entregas

Puntos SQA

Marco de trabajo del proceso común

Actividades de trabajo del proceso común

Conjunto de tareas

• Las actividades de protección: tales como garantía de calidad del software, gestión de

configuración del software y medición, abarcan el modelo del proceso común , las

actividades de protección son independientes de cualquier actividad del marco de

trabajo y aparecen

durante todo el proceso.

Actividades de protección

Tareas

Hitos, entregas

Puntos SQA

Figura 1.5 Elementos del proceso del software.

Otra perspectiva utilizada para determinar los elementos del proceso de desarrollo de

software es establecer las relaciones entre elementos que permitan responder ¿quién debe

hacer qué?, ¿cuándo? y ¿cómo debe hacerlo?.

Roles

Personas

ActividadesRoles Artefactos

Proceso SW

Notación

Actividades

Practicas y principios

Roles

Personas

ActividadesRoles Artefactos

Proceso SW

Notación

Actividades

Practicas y principios

Figura 1.6 Relación entre elementos del proceso del software.

En base a la figura 1.4 donde se muestran los elementos de un proceso de desarrollo de

software y sus relaciones, las interrogantes se responden de la siguiente forma:

• ¿Quién?: las personas participantes en el proyecto de desarrollo desempeñando uno o

más trabajos específicos.

• ¿Qué?: un dispositivo el cual es producido por un rol en una de sus actividades, estos se

especifican utilizando marcas particulares, las herramientas apoyan la elaboración de

los mismos soportando ciertas notaciones.

16

• ¿Cómo y cuándo?: la relación de las actividades que se lleva a cabo durante el proceso

de desarrollo, el avance del proyecto está monitoreado mediante controles específicos

que establecen un determinado estado de terminación de ciertos artefactos.

La composición y sincronía de las actividades está basada en un conjunto de principios y

prácticas, estos enfatizan ciertas actividades y/o la forma como deben realizarse, por

ejemplo: desarrollar iterativamente, gestionar requisitos, desarrollo basado en componentes,

modelar visualmente, verificar continuamente la calidad, gestionar los cambios, etc.

1.4 Modelos de proceso software.

Su definición más común los considera como una representación simplificada de un

proceso de software, desde una perspectiva específica. Por su naturaleza, los modelos son

simplificados por lo tanto, un modelo de proceso del software es una abstracción de un

proceso real.

Los modelos genéricos no son descripciones definitivas; son abstracciones útiles que

pueden ser utilizadas para explicar diferentes enfoques del desarrollo de software.

Los siete modelos que han sido considerados son:

• Codificar3 y corregir.

• Modelo en cascada.

• Desarrollo evolutivo.

• Desarrollo formal de sistemas.

• Desarrollo basado en reutilización.

• Desarrollo incremental.

• Desarrollo en espiral.

3 Codifica: Ver Glosario

17

1.4.1 Codificar y corregir.

Este es el modelo básico utilizado en los inicios del desarrollo de software, basado en dos

pasos:

• Escribir código.

• Corregir problemas en el código.

Consiste en, implementar algo de código y luego pensar acerca de requisitos, diseño,

validación, y mantenimiento.

Este modelo tiene tres problemas principales:

• Después de un número de correcciones, el código puede tener una muy mala estructura,

hace que los arreglos sean muy costosos.

• Frecuentemente, aún el software bien diseñado, no se ajusta a las necesidades del

usuario, por lo que es rechazado o su reconstrucción es muy cara.

• El código es difícil de reparar por su pobre preparación para probar y modificar.

1.4.2 Modelo en cascada.

El primer modelo de desarrollo de software que se publicó, se derivó de otros procesos de

ingeniería, toma las actividades fundamentales del proceso de especificación, desarrollo,

validación, evolución y representandolas como fases separadas del proceso.

• Definición de los requisitos: los servicios, restricciones y objetivos son establecidos con

los usuarios del sistema. Se busca hacer esta definición en detalle.

• Diseño de software: Se particiona el sistema en sistemas de software o hardware, se

establece la arquitectura total del sistema. Se identifican y describen las abstracciones

y relaciones de los componentes del sistema.

• Implementación y pruebas unitarias: se construyen módulos y unidades de software

realizándose pruebas en cada unidad.

• Integración y pruebas del sistema: se integran todas las unidades, se prueban en

conjunto, se entrega probado al cliente.

18

• Operación y mantenimiento: generalmente es la fase más larga, el sistema es puesto en

marcha y se realiza la corrección de errores descubiertos, haciendo mejoras de

implementación e identifican nuevos requisitos.

La interacción entre fases puede observarse en la figura 1.5, cada fase tiene como resultado

documentos que deben ser aprobados por el usuario.

Una fase no comienza hasta que termine la fase anterior y generalmente se incluye la

corrección de los problemas encontrados en fases previas.

Definición de

Requisitos

Diseño de sistema y Software

Implementación y Pruebas de Unidad

Integración y Prueba de Sistema

Operación y Mantenimiento

Definición de Requisitos

Diseño de sistema y Software

Implementación y Pruebas de Unidad

Integración y Prueba de Sistema

Operación y Mantenimiento

Figura 1.7 Modelo de desarrollo en cascada.

En la práctica, este modelo no es lineal, e involucra varias iteraciones4 e interacción entre

las distintas fases de desarrollo, algunos problemas que se observan en el modelo de

cascada son:

• Las iteraciones son costosas e implican rehacer trabajo debido a la producción y

aprobación de documentos.

• Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con

las siguientes fases.

• Los problemas se dejan para su posterior resolución, lo que lleva a que estos sean

ignorados o corregidos de una forma poco elegante.

• Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario

4 Iteraciones: Ver Glosario

19

por el largo tiempo de entrega del producto.

• Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difícil

responder a cambios en los requisitos.

Este modelo sólo debe usarse si se entienden a plenitud los requisitos aún se utiliza como

parte de proyectos grandes.

1.4.3 Desarrollo evolutivo.

El objetivo primordial de este modelo es el desarrollo de una implantación del sistema

inicial, exponerla a los comentarios del usuario, refinarla en n versiones hasta que se

desarrolle el sistema adecuado, en la figura 1.6 se observa cómo las actividades

concurrentes: especificación, desarrollo y validación; se realizan durante el desarrollo de las

versiones hasta llegar al producto final.

Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que

las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.

Bosquejo de la Descripción

Especificación

Desarrollo

Validación

Versión Inicial

Versiones Intermedias

Versión Final

Actividadesconcurrrentes


Especificación

Desarrollo

Validación

Versión Inicial


Versión Final


Especificación

Desarrollo

Validación

Versión Inicial


Versión Final

Actividadesconcurrrentes

Figura 1.8 Modelo de desarrollo evolutivo.

Existen dos tipos de desarrollo evolutivo:

• Desarrollo exploratorio: el objetivo de este enfoque es explorar con el usuario los

requisitos hasta llegar a un sistema final, el desarrollo comienza con las partes que se

20

tiene más claras, evolucionando conforme se añaden nuevas características propuestas

por el usuario.

• Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y

trabajar para mejorar la calidad de los requisitos, a diferencia del desarrollo

exploratorio, se comienza por definir los requisitos que no están claros para el usuario

y se utiliza un prototipo para experimentar con ellos el prototipo ayuda a terminar de

definir estos requisitos.

Entre los puntos favorables de este modelo están:

• La especificación puede desarrollarse de forma creciente.

• Los usuarios y desarrolladores logran un mejor entendimiento del sistema, esto se refleja

en una mejora de la calidad del software.

• Es más efectivo que el modelo de cascada, ya que cumple con las necesidades

inmediatas del cliente.

Desde una perspectiva de ingeniería y administración se identifican los siguientes

problemas:

• Proceso no visible: Los administradores necesitan entregas para medir el progreso. Si el

sistema se necesita desarrollar rápido, no es efectivo producir documentos que

reflejen cada versión del sistema.

• Sistemas pobremente estructurados: los cambios continuos pueden ser perjudiciales para

la estructura del software haciendo costoso el mantenimiento.

• Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con

otras o que poca gente sabe utilizar.

Este modelo es efectivo en proyectos pequeños (100,000 líneas de código) o medianos

(500,000 líneas de código) con poco tiempo para su desarrollo y sin generar documentación

para cada versión.

Para proyectos largos es mejor combinar lo mejor del modelo de cascada y evolutivo: se

puede hacer un prototipo global del sistema y posteriormente reimplementarlo con un

21

acercamiento más estructurado, los subsistemas con requisitos bien definidos y estables se

pueden programar utilizando cascada y la interfaz de usuario se puede especificar

utilizando un enfoque exploratorio.

1.4.4 Desarrollo formal de sistemas.

Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un

programa ejecutable.

La figura 1.7 ilustra un paradigma ideal de programación automática, se distinguen dos

fases globales: especificación y transformación, la característica principal de este

paradigma es que, la especificación es formal y ejecutable, constituye el primer prototipo

del sistema y es validada mediante prototipos.

Especificación TranformaciónInteractiva

TransformaciónAutomática

OptimizaciónValidación deEspecificación

Mantenimiento

Especificaciónde alto nivel (prototipo)

DesarrolloFormalDesiciones

Especificaciónde bajo nivel

CódigoFuente

EspecificaciónInformal

Figura 1.9 Paradigma de programación automática.

Posteriormente, a través de transformaciones formales la especificación se convierte en la

implementación del sistema, en el último paso se obtiene un modelo terminado en un

lenguaje de programación determinado. El mantenimiento se realiza sobre las

descripciones, no sobre el código fuente, la documentación es generada automáticamente y

el mantenimiento es realizado por repetición del proceso no mediante parches sobre la

implementación.

22

Observaciones sobre el desarrollo formal de sistemas:

• Permite demostrar la corrección del sistema durante el proceso de transformación, así las

pruebas que verifican la correspondencia con la especificación no son necesarias.

• Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad

importantes.

• Para llevarse a cabo, requiere desarrolladores especializados y experimentados en este

proceso.

1.4.5 Desarrollo basado en reutilización.

Es un modelo fuertemente orientado a la volver a utilizar las partes que ya estén

conformadas, consta de 4 fases, las cuales gráficamente se ven en la figura 1.8.

Análisis de componentes: Se determina qué elementos pueden ser utilizados para el sistema

en cuestión, regularmente hay que hacer ajustes para adecuarlos.

• Modificación de requisitos: se adaptan en lo posible, para concordar con los elementos

de la etapa anterior, si no se puede realizar modificaciones en los requisitos hay que

seguir buscando componentes más adecuados.

• Diseño del sistema con reutilización: se diseña o reutiliza el marco de trabajo para el

sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para

diseñar o determinar este marco.

• Desarrollo e integración: el software que no puede comprarse, se desarrolla, se integran

los mecanismos y subsistemas, la integración es parte del desarrollo en lugar de una

actividad separada.


Análisis de Componentes

Modificación de Requisitos

Diseño del sistema con Reutilización

Desarrollo e Integración

Validación del Sistema


Análisis de Componentes

Modificación de Requisitos

Diseño del sistema con Reutilización

Desarrollo e Integración

Validación del Sistema

Figura 1.10 Desarrollo basado en reutilización de componentes.

23

Ventajas:

• Disminuye el costo y esfuerzo de desarrollo.

• Reduce el tiempo de entrega.

• Disminuye los riesgos durante el proceso.

Desventajas:

• Los compromisos en los requisitos son inevitables, por lo cual puede que el software no

cumpla las expectativas del cliente.

• Las actualizaciones de los componentes adquiridos no están en manos de los

desarrolladores del sistema.

1.4.6 Procesos iterativos.

Especialmente diseñados para el soporte de las iteraciones:

• Desarrollo incremental.

• Desarrollo en espiral.

1.4.6.1 Desarrollo incremental.

El enfoque incremental de desarrollo se describe como una forma de reducir la repetición

del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones

en los requisitos hasta adquirir experiencia con el sistema, es una combinación del modelo

de cascada y el modelo evolutivo. Ver figura 1.9.

Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las

decisiones hasta tener experiencia en el sistema.

Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o

evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a implementar.

Si se tiene un buen conocimiento se puede optar por cascada, si es dudoso, el evolutivo.

24

Definición Bosquejo de Requisitos

Asignar Requisitos a los incrementos

Diseñar laArquitectura del Sistema

Desarrollo Incrementos del Sistema

Validad Incrementos

Integrar Incrementos Validad Sistema Sistema

Final

Sistema Incompleto

Definición Bosquejo de Requisitos

Asignar Requisitos a los incrementos

Diseñar laArquitectura del Sistema

Desarrollo Incrementos del Sistema

Validad Incrementos

Integrar Incrementos Validad Sistema Sistema

Final

Sistema Incompleto

Figura 1.11 Modelo de desarrollo iterativo incremental.

Entre las ventajas del modelo incremental se encuentran:

• Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema, pueden

empezar a usarlo desde el primer incremento, pueden aclarar los requisitos que no

tengan claros conforme ven las entregas del sistema.

• Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada

incremento.

• Las partes más importantes del sistema son entregadas primero, por lo cual se realizan

más pruebas en estos módulos y se disminuye el riesgo de fallos.

Algunas de las desventajas identificadas para este modelo son:

• Cada incremento debe ser pequeño para limitar el riesgo menos de 20,000 líneas,

debiendo aumentar la funcionalidad.

• Es difícil establecer las correspondencias de los requisitos contra los incrementos y

detectar las unidades o servicios genéricos para todo el sistema.

1.4.6.2 Desarrollo en espiral.

El modelo de desarrollo en espiral ilustrado en la figura 1.10, es actualmente uno de los

más conocidos, el ciclo de desarrollo se representa como una espiral, en lugar de una serie

de actividades sucesivas con retrospectiva de una actividad a otra.

Cada ciclo de desarrollo se divide en cuatro fases:

25

• Definición de objetivos:

Se definen los objetivos.

Se definen las restricciones del proceso y del producto.

Se realiza un diseño detallado del plan administrativo.

Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de

estos.

• Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada riesgo

identificado, pueden desarrollarse prototipos para disminuir el riesgo de requisitos

dudosos llevando a cabo los pasos para reducir los riesgos.

• Desarrollo y validación: Se escoge el modelo de desarrollo después de la evaluación del

riesgo. El modelo que se utilizará (cascada, sistemas formales, evolutivo, etc.)

depende del riesgo identificado para esa fase.

• Planificación: Se determina si continuar con otro ciclo, aquí se planea la siguiente fase

del proyecto.

Este modelo a diferencia de los otros toma en consideración explícitamente el riesgo, esta

es una actividad importante en la administración del proyecto.

El ciclo de vida inicia con la definición de los objetivos, de acuerdo a las restricciones se

determinan distintas alternativas:

• Identificar los riesgos al sopesar los objetivos contra las alternativas.

• Evaluar los riesgos con actividades como análisis detallado.

• Simulación.

• Prototipos, se desarrolla un poco el sistema y se planifica la siguiente fase.

26

Figura 1.12 Modelo de desarrollo en espiral

A ciencia cierta no se sabe cual modelo es el más adecuado ya que cada proyecto de

software requiere de una forma particular de abordar los requerimientos, las propuestas

comerciales y académicas actuales promueven procesos iterativos, donde en cada iteración

puede utilizarse uno u otro modelo de proceso, considerando un conjunto de criterios.

En la tabla 1.1 se expone un cuadro comparativo de acuerdo con algunos criterios básicos

para la selección de un modelo de proceso, la medida utilizada indica el nivel de efectividad

del modelo de proceso de acuerdo al criterio por ejemplo: el modelo cascada responde con

un nivel de efectividad bajo cuando los requisitos y arquitectura no están predefinidos.

27

Tabla 1.2 Comparación entre modelos de proceso de software.

Funciona con Produce Permite Visión del Modelo de

requisitos y Software Gestión

de correcciones progreso por arquitectura altamente sobre la el cliente y el

Proceso no predefinidos fiable

Riesgos marcha jefe del proyecto

Codificar y corregir

Bajo Bajo Bajo Alto Medio

Cascada Bajo Alto Bajo Bajo Bajo Evolutivo Medio o Medio o Medio o Medio o

exploratorio Alto Alto Medio

Alto Alto Evolutivo

prototipado Alto Medio Medio Alto Alto

Desarrollo formal Bajo o de sistemas

Bajo Alto Medio

Bajo Bajo

1.5 Metodologías para desarrollo de software.

Un proceso de software detallado y completo suele denominarse “metodología”, las

metodologías se basan en una combinación de los modelos de proceso genéricos (cascada,

evolutivo, incremental, etc.). Adicionalmente esta debería definir con precisión los

artefactos5, roles y actividades involucrados, junto con prácticas y técnicas recomendadas,

guías de adaptación al proyecto, monitoreos para uso de herramientas de apoyo, etc.

Habitualmente se utiliza el término “método” para referirse a técnicas, notaciones y guías

asociadas, que son aplicables a una o algunas actividades del proceso de desarrollo, por

ejemplo, suele hablarse de métodos de análisis y/o diseño.

La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la

diversidad de propuestas y diferencias en el grado de detalle, información disponible y

alcance de cada una de ellas, a grandes rasgos, si se toman como criterio las notaciones

utilizadas para especificar artefactos producidos en actividades de análisis y diseño, se

podrán clasificar las metodologías en dos grupos: estructuradas y orientadas a objetos. Por

otra parte, considerando su filosofía de desarrollo, aquellas con mayor énfasis en la

5 Artefactos: Ver Glosario

28

planificación y control del proyecto en especificación precisa de requisitos y modelado6,

reciben el apelativo de tradicionales o pesadas, otras denominadas ágiles, están más

orientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen a

equipos de desarrollo pequeños, hacen especial hincapié en aspectos humanos asociados al

trabajo en equipo e involucran activamente al cliente en el proceso, a continuación se

revisan brevemente cada una de estas categorías.

1.5.1 Metodologías estructuradas.

Los métodos estructurados comenzaron a desarrollarse a fines de los años setentas con la

programación estructurada, luego aparecieron técnicas para el diseño y posteriormente para

el análisis, estas metodologías son particularmente apropiadas en proyectos que utilizan

para la implementación, lenguajes de tercera y cuarta generación.

1.5.2 Metodologías orientadas a objetos.

Su historia va unida a la evolución de los lenguajes de programación orientada a objeto, los

más representativos: a fines de los años sesentas y setentas “simula y smalltalk-80”7, la

primera versión de C++ en 1981 y actualmente Java8 o C# de Microsoft.

Se ha propuesto el método unificado con la idea de conseguir una unificación de sus

métodos y notaciones, que posteriormente se reorienta a un objetivo más modesto, para dar

lugar al lenguaje unificado de modelado, Unified Modeling Language (UML), la notación

orientado a objeto más popular en la actualidad.

Algunas metodologías orientadas a objetos que utilizan la notación UML son: proceso

unificado racional, Rational Unified Process (RUP).

6 Modelado: Ver Glosario. 7 Simula y smalltalk-80: lenguajes de programación utilizados en la década de los años setentas. 8 Java: Lenguaje de programación orientado a objetos multiplataforma, actualmente utilizado con muy buena aceptación.

29

1.5.3 Metodologías ágiles.

Un proceso es ágil cuando el desarrollo de software es incremental, se realizan entregas

pequeñas con ciclos rápidos, cooperativo donde el cliente y desarrolladores trabajan juntos

constantemente con una cercana comunicación. Es sencillo, siendo el método más fácil de

aprender y modificar, además de estar bien documentado y adaptable, permitiendo realizar

cambios de último momento.

1.5.4 Metodologías tradicionales o no ágiles.

Son aquellas que están guiadas por una fuerte planificación durante todo el proceso de

desarrollo; llamadas también clásicas, donde se realiza una intensa etapa de análisis y

diseño antes de la construcción del sistema.

1.6 Seguridad en redes.

En la actualidad, las organizaciones son cada vez más dependientes de sus redes

informáticas y un problema que las afecte por mínimo que sea puede llegar a comprometer

la continuidad de las operaciones.

La falta de medidas de seguridad en las redes es un problema que está en crecimiento.

Cada vez es mayor el número de atacantes y cada vez están más organizados, por lo que,

van adquiriendo día a día habilidades más especializadas que les permiten obtener mayores

beneficios.

La propia complejidad de la Internet es una dificultad para la detección y corrección de los

múltiples y variados problemas de seguridad que van apareciendo, en medio de esta

variedad, han ido aumentando las acciones poco respetuosas de la privacidad y de la

propiedad de recursos y sistemas. “hackers”9, “crakers10”, entre otros, han hecho aparición

en el vocabulario ordinario de los usuarios y de los administradores de las redes. 9 Hackers: Ver Glosario. 10 Crakers; Ver Glosario.

30

Además de las técnicas y herramientas criptográficas11, es importante recalcar que un

componente muy importante para la protección de los sistemas consiste en la atención y

vigilancia continua sistemática por parte de los responsables de la red.

A la hora de plantearse en qué elementos del sistema se deben ubicar los servicios de

seguridad, podrían distinguirse dos tendencias principales:

• Protección de los sistemas de transferencia o transporte: en este caso, el administrador

de un servicio asume la responsabilidad de garantizar la transferencia segura al

usuario final de la información lo más transparente posible. Ejemplos de este tipo de

planteamientos serían el establecimiento de un nivel de transporte seguro, de un

servicio de mensajería con agentes de transporte de seguras, o la instalación de un

firewall, que defiende el acceso a una parte protegida.

• Aplicaciones seguras extremo a extremo: si pensamos, por ejemplo, en el correo

electrónico, consistiría en construir un mensaje en el cual el contenido ha sido

asegurado mediante un procedimiento de encapsulado previo al envío, de esta forma,

el mensaje puede atravesar sistemas heterogéneos y poco fiables sin por ello perder la

validez de los servicios de seguridad provistos, aunque el acto de asegurar el mensaje

cae bajo la responsabilidad del usuario final, es razonable pensar que dicho usuario

deberá usar una herramienta amigable proporcionada por el responsable de seguridad

de su organización, esto mismo puede usarse para abordar el problema de la

invulnerabilidad en otras aplicaciones tales como videoconferencia, acceso a bases de

datos, etc.

En ambos casos, un problema de vital importancia es la gestión de contraseñas, este

problema es inherente al uso de la criptografía y debe estar resuelto antes de que el usuario

esté en condiciones de enviar un solo bit seguro.

11 Criptográficas: Ver Glosario.

31

1.6.1 Dimensión del valor de los datos.

Establecer el valor de los datos es algo totalmente relativo, pues la información constituye

un recurso que, en muchos casos, no se valora adecuadamente debido a su intangibilidad,

cosa que no ocurre con los equipos, la documentación o las aplicaciones. Además las

medidas de seguridad no influyen en la productividad del sistema por lo que las

organizaciones son reticentes a dedicar recursos a esta tarea.

Cuando se habla del valor de la información es referirse, por ejemplo: a qué tan peligroso

es enviar la información de las tarjetas de crédito a través de Internet para hacer una

compra. En una red gigantesca donde viajan no únicamente los 16 dígitos de esta tarjeta de

crédito sino millones de datos más (gráficas, voz y vídeo), algunos expertos opinan que se

corre más peligro cuando se entrega una tarjeta de crédito al empleado de un restaurante o

cuando se la emplea telefónicamente para efectivizar alguna compra.

El peligro más grande no radica en enviar la información sino, una vez que esta

información unida a la de miles de clientes más, se encuentra en una base de datos de la

compañía con las que se concretó el negocio, con un único acceso no autorizado a esta base

de datos es posible que alguien además de los datos y los de la tarjeta de un cliente también

los datos y tarjetas de todos los clientes de la compañía.

En consecuencia, el tema no está restringido únicamente a Internet, aunque no se esté

conectado a ésta, una red está expuesta a distintos tipos de ataques electrónicos, incluidos

los virus.

1.6.2 Definiendo seguridad en redes.

Dado que se está tratando con conceptos que pueden tener múltiples interpretaciones,

parece prudente acordar ciertos significados específicos.

Seguridad: es “calidad de seguro”, y, seguro está definido como “libre de riesgo”.

32

Información: es “acción y efecto de informar”.

Informar: es “dar noticia de una cosa”.

Redes: es “el conjunto sistemático de hilos conductores o de vías de comunicación o de

agencias y servicios o recursos para determinado fin”.

Uniendo estas definiciones, podemos establecer qué se entiende por seguridad en redes: la

provisión de información libre de riesgo y brindar servicios para un determinado fin.

También podemos considerar una definición más: seguridad en redes es mantener bajo

protección los recursos y la información con que se cuenta en la red, a través de

procedimientos basados en una política de seguridad tales que, permitan el control de lo

actuado.

33

Capítulo II.- Etapas del proceso de software.

2.1 Introducción.

Un sistema de software tiene un ciclo de vida que comienza con la formulación de un

problema, seguido por la especificación de requisitos, análisis, diseño, implementación,

pruebas del software y mantenimiento del software, continuado de una fase operacional

durante la cual se mantiene y extiende el sistema. Los sistemas informáticos al agilizar y

optimizar el almacenamiento, difusión y procesamiento de la información, mejoran la

producción de las organizaciones que los emplean para la automatización de sus funciones.

Sin embargo, si no se tienen en cuenta ciertos elementos en el diseño e implantación no

siempre la automatización, significa un aumento de la producción.

Por lo tanto, antes de iniciar una automatización es importante tener en cuenta que:

• Las organizaciones son complejas y realizan diversas funciones que están relacionadas

entre si, que sus necesidades de manejo de información cambian y crecen, y que

además del manejo operativo de la información hay una necesidad de contar con un

acceso global que permita una mejor toma de decisiones.

• La tecnología es muy cambiante, cada vez hay mayor variedad de equipos y sistemas

más poderosos de costos diversos, lo que complica la selección de la tecnología

adecuada.

• El diseño, la programación y la operación de los sistemas requieren de especialistas.

Por lo antes mencionado si se pretende que realmente una automatización no solamente

redunde en una mejora de la producción sino que además resulte una inversión rentable en

34

cuanto a la adquisición de una tecnología adecuada, es necesario contar con una

metodología de desarrollo de sistemas.

Dado que el desarrollo de sistemas de información es una actividad compleja, ésta puede

dividirse para su estudio en las siguientes etapas:

1. Definición y análisis de los requerimientos del usuario.

2. Diseño del sistema y de la base de datos.

3. Implantación y prueba de módulos.

4. Integración y prueba del sistema.

5. Operación y mantenimiento.

Como estas etapas a su vez son muy elaboradas, han surgido varias metodologías que

permiten realizarlas de una manera estructurada, el método CASE utiliza diversas

aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de

software reduciendo el costo de las mismas en términos de tiempo y de dinero, plantea una

secuencia que proporciona para cada etapa su descripción, definición de objetivos y metas,

productos, factores críticos de éxito, y la lista de tareas que conviene realizar.

2.2 Etapas en el método CASE.

La metodología de este método se basa en un análisis y desarrollo del tipo descendiente en

que el ciclo de vida de un sistema se compone de las siguientes etapas:

• Estrategia

• Análisis

• Diseño

Construcción

Documentación

• Transición

• Producción

35

Estrategia

Análisis

Diseño

Transición

Producción

DocumentaciónConstrucción

Estrategia

Análisis

Diseño

Transición

Producción

DocumentaciónConstrucción

Figura 2.1 Etapas del método CASE.

2.2.1. Estrategia.

Es una de las etapas más importantes, tiene por objetivo lograr un entendimiento claro de

las necesidades de la organización y del ambiente en que operará el sistema a implantar.

Con el fin de tener una visión desde los puntos de vista de la dirección corporativa, se

analizan las diferentes funciones que realiza la organización y sus necesidades de

información a todos niveles, durante esta etapa se realizan una serie de entrevistas con la

dirección y los responsables de los departamentos, así a partir de esta información se

realiza un primer modelado de los requerimientos adecuado a las necesidades de la

organización. Consecutivamente para la definición de una primera versión de la

arquitectura del sistema, además de los requerimientos antes obtenidos, se toman en cuenta

las tecnologías en ese momento disponibles y los sistemas de información ya existentes en

operación.

Los resultados de esta etapa son un conjunto de modelos de la empresa, recomendaciones,

y un plan acordado de desarrollo de los sistemas de información. La elaboración de este

último se hará de acuerdo las necesidades actuales y futuras de la organización, tomando en

cuenta restricciones operativas, financieras y técnicas.

36

Funciones de la

organización

Sistemas existentes

Necesidades de sistemas de información

Definición de la arquitectura del

sistema

Requerimientos de Información

Análisis / Modelación Estratégica

DirecciónCorporativa

Tecnologíasdisponibles

Funciones de la

organización

Sistemas existentes

Necesidades de sistemas de información

Definición de la arquitectura del

sistema

Requerimientos de Información

Análisis / Modelación Estratégica

DirecciónCorporativa

Tecnologíasdisponibles

Figura 2.2 Etapa de estrategia.

2.2.2 Análisis.

La etapa de análisis toma y verifica los descubrimientos de la etapa de estrategia y expande

estos en suficientes detalles para asegurar la precisión de los modelos de la empresa

posibilitando un fundamento sólido para el diseño. Dentro del alcance de la organización y

tomando en cuenta sistemas existentes a un nivel operativo y técnico, con el fin de obtener

un refinamiento de los modelos y asegurando la participación de los responsables de la

operación, se realiza un análisis detallado de sus requerimientos específicos en cuanto a

objetivos, funciones, información, datos, reportes, etc.

A partir de los modelos de la organización obtenidos en la anterior etapa y del producto del

análisis de ésta, se genera el modelado del sistema. Los modelos básicos de esta etapa son:

• Entidad-relación, que modela mediante relaciones lógicas todos los datos involucrados

en el sistema, de tal manera que cualquier tipo de explotación consulta o modificación

sea posible.

• Funcional, que modela los diferentes servicios que ofrecerá el sistema mediante una

organización y clasificación de las diversas funciones y subfunciones que fueron

identificadas en el análisis.

• Como resultados, se definen las restricciones que tendrá el sistema y la estrategia que se

37

seguirá en la etapa de transición.

Modelofuncional

Análisis de Documentos

Definición de la transición

Modelo entidad relación

Análisisde datos

Análisis Modelación

Sistema

Análisis de funciones

Definición de restricciones

Entrevistas

Modelofuncional

Análisis de Documentos

Definición de la transición

Modelo entidad relación

Análisisde datos

Análisis Modelación

Sistema

Análisis de funciones

Definición de restricciones

Entrevistas

Figura 2.3. Etapa de análisis

2.2.3 Diseño.

Aquí se toman los requerimientos y el modelado de la etapa de análisis, determina la mejor

manera de satisfacerlos logrando niveles de servicios acordados, en base al ambiente

técnico y las decisiones previas en los niveles requeridos de automatización, es decir, que

del diseño conceptual se pasa al diseño final que será utilizado para la implantación. Aquí

el modelo entidad-relación será transformado en un diseño de base de datos, y en

especificaciones de almacenamiento y el modelo de funcional, en módulos y manuales de

procedimientos.

El diseño final del sistema integra tres diseños más, el de la base de datos, de la aplicación

y el de la red; además se elaboraran los planes de prueba y de transición, se realizan los

sistemas de auditoria y control, el de respaldos y recuperación, los resultados de esta etapa

lo constituyen, la arquitectura del sistema, el diseño de la base de datos, la especificación de

los programas, la especificación de los manuales de procedimientos.

38

Especificación de los manuales de procedimientos

Diseño de laRed

Plan de

Pruebas

Arquitectura del Sistema

Diseño de sistema

de Auditoria y

control

Diseño final

Diseño de la Base de Datos

Especificación de los programas

Diseño de sistema de Respaldo


Plan de transición

Diseño de la

Aplicación

Especificación de los manuales de procedimientos

Diseño de laRed

Plan de

Pruebas


Diseño de sistema

de Auditoria y

control

Diseño final



Diseño de sistema de Respaldo


Plan de transición

Diseño de la

Aplicación

Figura 2.4 Etapa de diseño.

2.2.3.1 Construcción.

A partir del diseño final generado en la etapa anterior, en esta se codificarán y probarán los

nuevos programas, usando herramientas apropiadas. Aquí se involucra la planeación,

diseño de la estructura del sistema, codificación, y un enfoque disciplinado en la realización

del trabajo y en el control de versiones del sistema; los resultados de esta etapa son los

programas probados y la base de datos afinada.


Herramientas

Programasprobados


Construcción

Diseño de la Base de Datos Base de datos

afinada


Herramientas

Diseño de la Base de Datos Base de datos

afinada

Programasprobados


Construcción

Figura 2.5 Etapa de construcción.

39

2.2.3.2 Documentación.

Esta metodología incluye una etapa dedicada a la elaboración de los manuales y hace

hincapié para que en su construcción se consideren el estilo de trabajo y las necesidades

propias de los usuarios que utilizarán y mantendrán el sistema. Se realiza paralelamente a

la etapa de construcción.

Los manuales se elaboran a partir de las especificaciones de diseño, de los programas

realizados, del análisis del estilo de trabajo, y nivel de competencia de los usuarios y

operadores de los sistemas.

Manual Técnico

Programas probados

Estilo de trabajo de los usuarios

Manual de

usuario

Construcción

Especificación de los

programas Manual Técnico

Programas probados

Estilo de trabajo de los usuarios

Manual de

usuario

Construcción

Especificación de los

programas

Figura 2.6 Etapa de documentación.

2.2.4 Transición.

En ella se realizan todas las tareas necesarias para la implementación y proporciona un

periodo inicial de soporte al sistema, debe llevarse a cabo con una interrupción mínima de

la organización, dejando a los usuarios confiados y listos para explotar el nuevo sistema.

El resultado final de esta etapa es un reporte que muestre que las pruebas fueron

satisfactorias. La implantación de sistemas no necesariamente implica la sustitución total

de los antiguos subsistemas y de sus bases de datos correspondientes.

40

En ciertos casos, por razones operativas y/o económicas, los nuevos sistemas integran

algunos de los antiguos; la introducción ya sea de un sistema completamente nuevo o un

sistema que integra ya un nuevo tipo de uso y de operación que deberá ser asimilado y

aprendido por los usuarios y operadores. Por esta razón, el desarrollo de un sistema no se

termina con su programación; antes de su liberación para su uso se debe prever un período

de transición.

Nuevo Sistema

Capacitación

Reporte de las pruebas

Diseño final Subsistemas antiguos

Alimentación de la Base de Datos

Pruebas

Nuevo Sistema

Capacitación

Reporte de las pruebas

Diseño final Subsistemas antiguos

Alimentación de la Base de Datos

Pruebas

Figura 2.7 Etapa de transición.

2.2.5 Producción.

Es la etapa final la cual se asegura que el sistema funcione correctamente, para esto se

realizan nuevas pruebas, se reevalúan los resultados y se hacen refinamientos del sistema,

los cambios necesarios deberán ser introducidos sin afectar a los usuarios, debiéndose

conseguirse la máxima confianza, el resultado es un sistema listo para su operación.

Nuevo Programa

Prueba final Validaciones

Refinamientos

Sistema listo para su

operación

Producción Nuevo Programa Producción Sistema listo para su

operación

Prueba final Validaciones

Refinamientos

Figura 2.8 Etapa de producción.

41

2.3 Modelado de Software. Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan

expresar el producto desde cada una de las perspectivas de interés.

El código fuente es el modelo más detallado del sistema. Sin embargo, se requieren otros

modelos donde cada uno es diferente y completo desde el punto de vista del sistema,

existiendo relaciones de trazabilidad12 entre ellos.

El uso de modelos ayuda al desarrollador de software a visualizar el sistema a construir,

las herramientas de modelado y las de ingeniería de software ayudan a verificar

correcciónes, tal como lo hace UML.

2.3.1 UML.

Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling

Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en

la actualidad; es un lenguaje gráfico para visualizar, especificar, construir y documentar un

sistema de software, ofrece un estándar para describir un plano del sistema, incluyendo

aspectos conceptuales tales como procesos de negocios y funciones del sistema, aspectos

concretos como expresiones de lenguajes de programación, esquemas de bases de datos y

componentes de software reutilizables.

Se utiliza para definir un sistema de software, detallando los artefactos en el sistema,

documentar y construir, en otras palabras, es el lenguaje en el que está descrito el modelo.

12 Trazabilidad: Ver Glosario.

42

2.3.2. Herramientas de UML.

UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las

entidades representadas, estos expresan gráficamente partes de un modelo y enfatizan los

elementos que deben existir en el sistema modelado, existen:

• Diagrama de clases.

• Diagrama de componentes.

• Diagrama de objetos.

• Diagrama de actividades.

• Diagrama de casos de uso.

• Diagrama de estados.

• Diagrama de secuencia.

• Diagrama de colaboración.

Diagramas de Actividad

Diagramas de Distribución

Diagramas de Componentes

Diagramas de Objetos

Diagramas de Clases

Diagramas de caso de Uso

Diagramas de Secuencia

Diagramas de Colaboración

Diagramas de Estados

Modelos

Diagramas de Actividad




Diagramas de Clases




Diagramas de Estados Diagramas de

Actividad




Diagramas de Clases




Diagramas de Estados

Modelos

Figura 2.9 Clasificación de diagramas de UML.

2.3.2.1 Diagrama de casos de uso.

Es una técnica para capturar información respecto de los servicios que un sistema

proporciona a su entorno es utilizado para captura y especificación de requisitos. Muestra

la relación entre los actores y los casos de uso del sistema, un actor es algo con

43

http://es.wikipedia.org/wiki/Diagrama_de_clases

http://es.wikipedia.org/wiki/Diagrama_de_componentes

http://es.wikipedia.org/wiki/Diagrama_de_objetos

http://es.wikipedia.org/wiki/Diagrama_de_actividades

http://es.wikipedia.org/wiki/Diagrama_de_casos_de_uso

http://es.wikipedia.org/wiki/Diagrama_de_estados

http://es.wikipedia.org/wiki/Diagrama_de_secuencia

http://es.wikipedia.org/wiki/Diagrama_de_colaboraci%C3%B3n

comportamiento, como una persona identificada por un rol, o un sistema informatizado u

organización, y que realiza algún tipo de interacción con el sistema. Se representa

mediante una figura humana dibujada, mientras que un caso de uso es una descripción de la

secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa

el sistema para llevar a cabo una tarea específica, expresa una unidad coherente de

funcionalidad, y se representa en el diagrama mediante una elipse con el nombre del caso

en su interior, el nombre debe reflejar la tarea específica que el actor desea llevar a cabo

usando el sistema.

Actor Caso de UsoActor Caso de Uso

Figura 2.10 Ejemplo de actor y caso de uso.

2.3.2.2 Diagrama de Clases.

Es el diagrama principal para el análisis y diseño del sistema representa las clases, una

clase está representada por un rectángulo que dispone de tres apartados, el primero para

indicar el nombre, el segundo para los atributos y el tercero para los métodos, que serán

utilizados dentro del sistema y las relaciones que existen entre ellos, por definición son

estáticos, esto es, representan que partes interactúan entre sí.

Usuario

Nombre : CharDirección : CharSituación : int = 3

Entrar ()Salir()Trabajar()

Usuario

Nombre : CharDirección : CharSituación : int = 3

Entrar ()Salir()Trabajar()

Figura 2.11 Ejemplo de una clase.

44

2.3.2.3 Diagramas de estados.

Se usan para representar gráficamente máquinas de estados finitos, las tablas de

transiciones son otra posible representación, hay muchas formas de diagramas de estados

que difieren levemente y tienen semánticas diferentes.

2.3.2.4 Diagramas de actividad.

Caso especial de diagrama de estados donde: todos o la mayoría de los estados son estados

de acción. La mayoría de las transiciones son “disparadas” como consecuencia de la

finalización de la acción, puede especificar el comportamiento de los objetos de una clase,

la lógica de una operación de un caso de uso o la descripción de un flujo de trabajo.

2.3.2.5 Diagrama de componentes.

Permite modelar la estructura del software y la dependencia entre componentes, estos

últimos son un grupo de clases que trabajan estrechamente, pueden corresponder a código

fuente, binario o ejecutable, una relación de dependencia indica que un componente utiliza

otro, por lo cual depende de él.

2.3.2.6 Diagramas de secuencias.

Son usados para describir gráficamente un caso de uso o un escenario muestra los objetos

mediante líneas verticales y los mensajes entre ellos, como flechas conectando objetos, los

mensajes son dibujados cronológicamente desde arriba hacia abajo, los rectángulos en las

líneas verticales representan los periodos de actividad de los objetos.

45

Figura 2.12 Ejemplo de diagramas de secuencia.

2.3.2.7 Diagramas de colaboración.

Este diagrama modela la interacción entre los objetos de un caso de uso, los cuales están

conectados por enlaces (links) en donde se representan los mensajes enviados

acompañados de una flecha que indica su dirección

:WInPréstamos

:Socio

:Video

:Préstamo

1: prestar(video, socio)

2: verificar situación socio

3: verificar situación video

4: registrar préstamo5: entregar recibo

:WInPréstamos

:Socio

:Video

:Préstamo

1: prestar(video, socio)

2: verificar situación socio

3: verificar situación video

4: registrar préstamo5: entregar recibo

Figura 2.13 Ejemplo de diagramas de colaboración (para su entendimiento).

46

2.3.2.8 Diagrama de objetos.

Representa un conjunto de objetos y sus relaciones en un momento concreto, se utilizan

para describir estructuras de datos instantáneas de las instancias de los elementos

encontrados en un diagrama de clases, gráficamente es una colección de nodos y arcos

(Persona)Andrea

(Persona)Laura

(Persona)María

Objetos

(Persona)Andrea

(Persona)Laura

(Persona)María

Objetos

Figura 2.14 Ejemplo de diagramas de objetos.

2.4 Programación orientada a objetos.

La programación orientada a objetos es una forma de enfocar la tarea de programación,

desde la invención de las computadoras los enfoques han cambiado drásticamente la

creciente complejidad de los programas, antes las instrucciones máquina se realizaban

mediante una consola, esto funcionaba porque los programas sólo tenían pocas

instrucciones, cuando crecieron los programas, se invento el lenguaje ensamblador para que

el programador pudiera manejar programas más largos y complejos usando una

representación simbólica de las instrucciones máquina.

Este tipo de programación toma las mejores ideas de la programación estructurada, la

combina con nuevos conceptos permitiendo descomponer fácilmente un problema en

subgrupos de partes relacionadas, entonces, puede traducir estos subgrupos en unidades

auto contenidas llamadas objetos.

2.4.1 Definición.

Se puede definir como una técnica o estilo que utiliza objetos como bloque esencial de

construcción, es una forma especial de programar, más cercana a como expresaríamos las

47

cosas en la vida real, esto permite hacer los programas y módulos más fáciles de escribir,

mantener y reutilizar.

Al igual que los tipos de datos definidos por el usuario, un objeto es una colección de datos,

junto con las funciones asociadas, utilizadas para operar sobre esos datos. Sin embargo la

potencia real de los objetos reside en las propiedades que soportan: herencia, encapsulación y

polimorfismo, junto con los conceptos básicos de objetos, clases, métodos y mensajes.

2.4.2 Objetos.

Un objeto es una unidad que contiene datos y las funciones que operan sobre esos datos.

Los datos se denominan miembros dato y las funciones métodos o funciones miembro, son

entidades que combinan estado, comportamiento e identidad:

• El estado está compuesto de datos, serán uno o varios atributos a los que se habrán

asignado unos valores concretos (datos).

• El comportamiento está definido por los procedimientos o métodos con que puede

operar dicho objeto, es decir, qué operaciones se pueden realizar con él.

• La identidad es una propiedad de un objeto que lo diferencia del resto, dicho con otras

palabras, es su identificador.

• Los datos y las funciones se encapsulan en una única entidad, los datos están ocultos y

sólo mediante las funciones miembro es posible acceder a ellos.

2.4.3 Encapsulamiento y ocultación.

Cada objeto es una estructura compleja en cuyo interior hay datos y programas, todos ellos

relacionados entre sí, como si estuvieran encerrados conjuntamente en una cápsula a esta

propiedad se le llama encapsulamiento y es una de las características fundamentales en la

programación.

48

El hecho de que cada objeto sea una cápsula facilita ser transportado a otro punto de la

organización, o incluso a otra organización totalmente diferente que precise de él, y si ha

sido bien construido sus métodos seguirán funcionando en el nuevo entorno sin problemas,

son inaccesibles, e impiden que otros objetos, los usuarios, o incluso los programadores

conozcan cómo está distribuida la información, esta propiedad se denomina ocultación de

la información.

2.4.4 Clases.

Una clase es un tipo definido por el usuario que determina las estructuras de datos y las

operaciones asociadas con ese tipo, son definiciones de las propiedades y comportamiento

de un tipo de objeto concreto, cada vez que se construye un objeto de una clase, se crea una

instancia de esa clase. La instanciación es la lectura de estas definiciones y la creación de

un objeto a partir de ellas, los términos objetos e instancias se pueden utilizar indistintamente

una clase es una colección de objetos similares y un objeto es una instancia de una definición

de una clase.

2.4.5 Mensajes (activación de objetos).

Los objetos pueden ser activados mediante la recepción de mensajes, son peticiones simples

para que un objeto se comporte de una determinada manera, ejecutando una de sus funciones

miembro, la técnica de enviar mensajes se conoce como paso de mensajes.

Estructuralmente consta de tres partes:

• La identidad del objeto receptor.

• La función miembro del receptor cuya ejecución se ha solicitado.

• Cualquier otra información adicional que el receptor pueda necesitar para ejecutar el

método requerido.

La comunicación con el objeto se realiza a través del paso de mensajes, el envío a una

instancia de una clase produce la ejecución de un método o función miembro, el paso de

49

mensajes es el término utilizado para referirnos a la invocación o llamada de una función

miembro de un objeto.

2.4.6 Herencia.

Es la propiedad que permite a los objetos construirse a partir de otros objetos, una clase se

puede dividir en subclases, en el lenguaje C++ la clase original se denomina clase base;

las que se definen a partir de la clase base, compartiendo sus características y añadiendo

otras nuevas, se denominan clases derivadas estas pueden heredar código y datos de su

clase base añadiendo su propio código y datos a la misma, la herencia impone una relación

jerárquica entre clases en la cual una clase hija hereda de su clase padre, si una clase sólo

puede recibir características de otra clase base, la herencia se denomina herencia simple, si

recibe propiedades de más de una clase base, la herencia se denomina herencia múltiple

esta propiedad sirve para crear objetos que incorporen propiedades y métodos de otros

objetos, así se pueden construir unos objetos a partir de otros sin tener que reescribirlo

todo.

2.4.7 Polimorfismo.

Es la cualidad de tener más de una forma, se refiere al hecho de que una misma operación

puede tener diferente comportamiento en diferentes objetos, es la posibilidad de construir

varios métodos con el mismo nombre, pero con relación a la clase a la que pertenece cada

uno, con comportamientos diferentes, esto conlleva la habilidad de enviar un mismo

mensaje a objetos de clases diferentes, los objetos recibirían el mismo mensaje global pero

responderían a él de formas diferentes, sirve para que no tengamos que preocuparse sobre

lo que se está trabajando y abstraer para definir un código que sea compatible con objetos

de varios tipos.

50

2.5 Análisis.

El objetivo principal del análisis es transformar los requerimientos a una especificación

que describa cómo implementar el sistema, fundamentalmente consiste en obtener una

visión que se preocupa de ver que hace el sistema de software a desarrollar, por tal motivo

este se interesa en los requerimientos funcionales de una manera concisa y sin

ambigüedades, aunque parece una fase sencilla es todo lo contrario, debido al alto grado de

comunicación requerida entre el usuario, técnicos, documentación y gerente, así como las

propiedades que debe tener la especificación , siendo esta la representación formal de los

requerimientos para un posterior diseño.

En esta etapa se analizan las necesidades de los usuarios finales del software para

determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD

(Documento de Especificación de Requisitos), que contiene la especificación completa de

lo que debe hacer el sistema sin entrar en detalles internos.

La siguiente tabla indica a quien y que facilita el análisis:

Tabla 2.1 Funcionalidad del modelo de análisis.

A quién Qué

Ingeniero de sistema

Especificar función y rendimiento. Interfaces otros elementos del sistema. Establecer las ligaduras de diseño que debe cumplir el sistema.

Ingeniero de Software Redefinir la asignación del software. Representa el dominio de la información que será tratada.

Diseñador Representación de información que puede traducirse en: estructura de datos, arquitectura del software, diseño procedimental

Técnico y cliente Proporcionando medios para valorar la calidad del sistema una vez construido

Un análisis de sistema se lleva a cabo teniendo en cuenta los siguientes objetivos: al

principio de la fase hay que definir una arquitectura candidata, crear un esquema inicial de

51

la arquitectura del sistema, identificar clases de análisis y actualizar las realizaciones de los

casos de uso con las interacciones de las clases de análisis, durante la fase de elaboración

se va refinando esta arquitectura hasta llegar a su forma definitiva, en cada iteración hay

que analizar el comportamiento para diseñar componentes.

Analizar el comportamiento del Sistema

Definir una Arquitectura Candidata

Diseñarlos servicios

Refinar la Arquitectura

ANALISIS Y DISEÑO

(Arquitectura Definida)

(Arquitectura no definida)

Diseñar loscomponentes

Diseñar la Base de Datos

Analizar el comportamiento del Sistema

Definir una Arquitectura Candidata

Diseñarlos servicios

Refinar la Arquitectura

ANALISIS Y DISEÑO

(Arquitectura Definida)

(Arquitectura no definida)

Diseñar loscomponentes

Diseñar la Base de Datos

Figura 2.15 Diagramas de análisis y diseño de un desarrollo de software.

2.5.1 Definición de una arquitectura candidata.

En esta actividad se debe proponer una arquitectura inicial para el software, incluye el

siguiente flujo de trabajo.

2.5.1.1 Especificación de requerimientos en el software ERS.

Describe las funciones del sistema, los requerimientos no funcionales, características del

diseño, y otros elementos necesarios para proporcionar una descripción completa y

comprensiva de los requerimientos para el software a desarrollar.

52

Los requerimientos pueden ser levantados con diferentes herramientas, es por ello que esta

metodología propone capturar todos los requerimientos en modelos que describen, como el

de casos de uso y especificaciones suplementarias.

El ERS controla la evolución del sistema durante todo el ciclo de desarrollo del proyecto,

cuando las nuevas características son añadidas o modificadas al artefacto de visión, son

aclarados dentro de éste.

Las decisiones hechas están basadas en información de los documentos de la propuesta del

proyecto, en requerimientos del usuario y deben ser satisfechos en el diseño del sistema.

2.5.1.2 Visión del sistema.

Se recomienda que este documento se conserve lo más claro y resumido posible para que

pueda llegar lo más pronto posible a los involucrados en el proyecto y para que sea más

fácil de entender por estos, debe incluir solamente las principales descripciones de los

requerimientos y evitar detalles específicos. Adicionalmente debe especificar volúmenes

de trabajo, tiempos de respuestas, precisión, perfiles de usuario, y límites del sistema.

2.5.1.3 Glosario del sistema.

Es una lista que contiene las definiciones de los términos a hacer utilizados durante la

realización del proyecto, que deben ser comprendidos por los participantes de tal manera

que haya una buena comunicación, evitar interpretaciones dispares o ambiguas, documentar

las definiciones de términos y acrónimos ayuda a ser más concisos y precisos.

2.5.1.4 Registro de riesgo.

Es un registro que refleja a manera de resumen todos los riesgos que han sido asociados al

proyecto en desarrollo. Este documento debe ser utilizado para monitorear y hacer

seguimiento de todas las acciones tomadas para la moderación de los riesgos identificados.

53

En este documento se relaciona cada riesgo identificado con sus acciones preventivas y de

contingencia, y es fundamental para la planificación de las iteraciones

2.5.1.5 Modelo de análisis.

Es usado para representar la estructura global del sistema, describe la realización de casos

de uso, sirve como una abstracción del modelo de diseño y se centra en los requerimientos

no funcionales, es un primer intento por definir los conceptos claves que describen el

sistema, es opcional, pero también tiene la propiedad de ser temporal en el caso en que se

planea su desarrollo, para representar los diagramas de este modelo se pueden emplear

diagramas de UML tales como diagramas de clase y de secuencia.

2.5.1.6 Modelo de diseño.

Fundamentalmente se emplea para representar y documentar, es usado como entrada

esencial en las actividades relacionadas a implementación.

2.5.1.7 Modelo de implantación.

Representa la implantación de los componentes del sistema en desarrollo sobre los

dispositivos físicos que se dispondrán para la ejecución del sistema.

2.5.1.8 Documento de una arquitectura de software.

Es una especificación de las ideas principales del diseño, proporciona una descripción

entendible de la arquitectura del sistema, sirve como medio de comunicación entre el

desarrollador de software y otros miembros de equipo del proyecto con respecto a las

decisiones significativas que se han tomado en el proyecto.

54

Especificaciones de Requerimientos del

Software (Modelo Caso de Uso)

Visión del Sistema

Glosario del Sistema

Registro del Riesgo

Arquitectura de Software

Analizar los Casos de Uso

Analizar la Arquitectura

Modelo de Análisis

Modelo de Diseño

Modelo de Implantación

Documento deArquitectura del Soft.

Modelo de Análisis

Modelo de Diseño (Realizaciones de los

Casos de Uso)

DEFINIR UNA ARQUITECTURA CANDIDATA

Figura 2.16 Definiendo una arquitectura candidata.

2.5.2 Análisis del comportamiento del sistema.

Esta actividad transforma las descripciones del comportamiento de los requerimientos en

un conjunto de elementos que permiten realizar el diseño del sistema, entre los elementos

mas importantes se encuentra: modelo de servicios, análisis, mapas de navegaciones,

prototipos de interfaz de usuario, registro de evaluaciones

2.5.2.1 Modelo de servicios.

Se emplea para concebir y documentar el diseño de los servicios que estarán presentes en el

sistema a desarrollar, se encuentra constituido por un grupo de servicios interconectados.

Con el fin de automatizar varios procesos del modelo puede contener uno o varios

diagramas, servicios, especificaciones, proveedores, particiones, mensajes, colaboraciones,

y todas las relaciones existentes entre ellos.

2.5.2.2 Mapa de navegación.

Expresa la estructura de los elementos de la interfaz de usuario del sistema, junto a los

caminos de navegación principales, permite al usuario una adecuada navegación en el

55

sistema y sobre todo saber en qué punto del sistema se encuentra y hacia donde puede ir.

Sin este no se podría aprovechar al máximo un sistema.

2.5.2.3 Prototipo de la interfaz de usuario.

Contiene todo lo relacionado con la interfaz, son elementos de diseño visual que permiten

al usuario tener una idea de las interfaces que mostrará el sistema, para obtener una

retroalimentación sobre los requerimientos, se realizan unas cuantas imágenes de pantalla

o un esqueleto de interfaz de usuario ejecutable, teniendo como propósito probar el diseño,

del software, de esta manera se valida que se esté cumpliendo con los requerimientos

exigidos antes de que se realice todo el esfuerzo necesario para el desarrollo.

2.5.2.4 Registro de evaluación.

Es el documento creado para registrar los resultados obtenidos de una evaluación aplicada a

uno ó más artefactos revisados del proyecto.


Identificar los elementos de Diseño


Modelo de AnálisisModelo de Diseño


Casos de Uso)


Analizar la Interfaz de Usuario

Generar Prototipo de la Interfaz de Usuario

Prototipo de la Interfaz de Usuario

Mapa de Navegación

Modelo de Servicio

Modelo de Análisis

Especificación deRequerimientos de

Software (Modelo de Caso de Uso))

Modelo de Servicio

Especificación de Requerimientos del

Software Mapa de Navegación

ANALIZAR EL COMPORTAMIENTO DEL SISTEMA

Modelo de Diseño

Modelo de Navegación



Registro de Evaluación


Identificar los elementos de Diseño


Modelo de AnálisisModelo de Diseño


Casos de Uso)



Generar Prototipo de la Interfaz de Usuario

Prototipo de la Interfaz de Usuario

Mapa de Navegación

Modelo de Servicio

Modelo de Análisis



Modelo de Servicio



ANALIZAR EL COMPORTAMIENTO DEL SISTEMA

Modelo de Diseño

Modelo de Navegación




Figura 2.17 Analizar el comportamiento del sistema.

56

2.6 Diseño

El diseño es un refinamiento que toma en cuenta los requerimientos no funcionales, por lo

cual se centra en como el sistema cumple sus objetivos.

Los objetivos específicos del análisis y diseño son:

• Transformar los requerimientos al diseño del futuro sistema.

• Desarrollar una arquitectura para el sistema.

• Adaptar el diseño para que sea consistente con el entorno de implementación.

Esta etapa consiste en trasladar los requerimientos del software a una representación, para

garantizar la calidad antes de comenzar la codificación es la etapa más importante y es

sobre la que descansa la calidad del producto software la importancia del diseño es tal, que

sin un buen diseño no existe un buen sistema, es el único medio para trasladar con precisión

los requerimientos del cliente en un producto o sistema acabado además de que sirve como

base para el resto de los pasos del desarrollo (código, pruebas), facilita el mantenimiento,

en términos generales un diseño debe de mostrar entre otras las siguientes características:

• Debe tener una organización jerárquica que haga un uso eficiente del control entre los

elementos del software.

• Ser modular: cada módulo debe realizar funcione específicas

• Contener una representación distinta y separable entre datos y procedimientos

• Conducir a módulos que muestren las máximas características de independencia

funcional

• Derivarse mediante un método repetible que este conducido por la información

obtenida de la fase de análisis de requerimientos.

57

2.6.1 Diseño de los servicios.

Esta actividad permite modelar el comportamiento de los servicios, identificar los

proveedores de servicio y las particiones.

Modelo de Servicios

Documento de la Arquitectura del Software

Modelo de Diseño


Software (Especificaciones Suplementarias)



Modelo de Servicios

Modelo de Diseño

DISEÑAR LOS SERVICIOS

Modelo de Servicios

Documento de la Arquitectura del Software

Modelo de Diseño


Software (Especificaciones Suplementarias)



Modelo de Servicios

Modelo de Diseño

DISEÑAR LOS SERVICIOS

Figura 2.18 Diseño los servicios.

2.6.2 Diseño de los componentes.

Esta actividad refina el diseño del sistema considerando el modelo elegido y obteniendo

una mejor perspectiva del diseño final deseado. En este proceso es importante contar con

un mapa de navegación, que por lo regular se puede incluir dentro del mismo sistema,

como guía de usuario.

58

Arquitectura de Software Diseñar las Clases

Diseñar Subsistemas

Modelo de DiseñoModelo de Diseño

Arquitectura de Software Diseñar Capsulas Diseñar los elementos

Soporte de Prueba


(Capsula)

Modelo de Análisis



Modelo de Diseño



DISEÑAR LOS COMPONENTES

Modelo de Diseño


Diseñar Casos de Uso

Arquitectura de Software Revisar el Diseño

Arquitectura de Software Diseñar las Clases

Diseñar Subsistemas


Arquitectura de Software Diseñar Capsulas Diseñar los elementos

Soporte de Prueba


(Capsula)

Modelo de Análisis



Modelo de Diseño



DISEÑAR LOS COMPONENTES

Modelo de Diseño


Diseñar Casos de Uso

Arquitectura de Software Revisar el Diseño

Figura 2.19 Diseño de los componentes.

2.6.3 Refinado de la arquitectura.

Es el último de los pasos, en esta etapa se genera un documento para registrar los

resultados obtenidos de una revisión aplicada a uno ó más artefactos generados del

proyecto de desarrollo de software, se revisan algunos de los artefactos que son generados

en el transcurso del proyecto se plasma los resultados y observaciones correspondientes a

la revisión de un artefacto en este documento.

2.7 Arquitectura de software.

Consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco

de referencia necesario para guiar la construcción del software para un sistema de

información, establece los fundamentos para que analistas, diseñadores, programadores,

etc. trabajen en una línea común que permita alcanzar los objetivos del sistema de

59

http://es.wikipedia.org/wiki/Software

http://es.wikipedia.org/wiki/Software

http://es.wikipedia.org/wiki/Sistema_de_informaci%C3%B3n

http://es.wikipedia.org/wiki/Sistema_de_informaci%C3%B3n

información, cubriendo todas las necesidades, mantiene unidas las nociones de diseño,

estructura, estilo, racionalidad, esta se selecciona y diseña con base en objetivos y

restricciones.

Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los

de tipo funcional, también otros como la mantenibilidad, auditabilidad, flexibilidad e

interacción con otros sistemas de información.

Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para

implementar sistemas de información, al mismo tiempo que define, de manera abstracta,

los componentes que llevan a cabo alguna tarea de computación, sus interfaces y la

comunicación ente ellos.

Toda arquitectura debe ser implementable en una arquitectura física, que consiste en

determinar qué computadora tendrá asignada cada tarea, tiene que ver con el diseño y la

implementación de estructuras de software de alto nivel.

Es el resultado de ensamblar un cierto número de elementos arquitectónicos de forma

adecuada para satisfacer la mayor funcionalidad y requerimientos de desempeño de un

sistema, así como requerimientos no funcionales, como la confiabilidad, escalabilidad,

portabilidad y disponibilidad.

2.7.1 Tipos de arquitectura de software.

Generalmente, no es necesario inventar una nueva arquitectura de software para cada

sistema de información, lo habitual es adoptar una conocida en función de sus ventajas e

inconvenientes para cada caso en concreto, las arquitecturas más universales son:

Monolítica. Donde el software se estructura en grupos funcionales muy acoplados.

60

http://es.wikipedia.org/wiki/Arquitectura

http://es.wikipedia.org/wiki/Computadora

http://es.wikipedia.org/w/index.php?title=Confiabilidad&action=edit&redlink=1

http://es.wikipedia.org/wiki/Escalabilidad

http://es.wikipedia.org/wiki/Portabilidad

http://es.wikipedia.org/wiki/Arquitectura_monol%C3%ADtica_%28inform%C3%A1tica%29

Cliente-servidor. Donde el software reparte su carga de cómputo en dos partes

independientes pero sin reparto claro de funciones.

Arquitectura de tres niveles. Especialización de la arquitectura cliente-servidor donde la

carga se divide en tres partes o capas con un reparto claro de funciones: una capa para la

presentación o interfaz de usuario, otra para el cálculo donde se encuentra modelado el

negocio y una más para el almacenamiento.

2.7.2 Documentación.

Para comenzar el desarrollo de la arquitectura de software es necesario partir de un

documento de especificación de requerimientos, en caso contrario deberemos trabajar de

manera formal en una etapa de requerimientos para definir de manera detallada lo que se

espera del sistema, el documento debe contener requerimientos funcionales del negocio, de

usuario, de sistema y requerimientos no funcionales: reglas de negocio, atributos de calidad

del sistema, interfaces externas, etc.

2.7.3 Patrones arquitectónicos.

De manera concreta, al diseñar una arquitectura de software se debe crear y representar

componentes que interactúen entre ellos y tengan asignadas tareas específicas, además de

organizarlos de forma tal que se logren los requerimientos establecidos se puede partir con

patrones de soluciones ya probados, con la intención de no comenzar de cero las propuestas

y utilizar modelos que han funcionado. Estas soluciones probadas se conocen como estilos

arquitectónicos, patrones arquitectónicos y de diseño, que van de lo general a lo particular.

Estilo arquitectónico: consiste de una colección de tipos de componentes con una

descripción del patrón o interacción a través de ellos, afecta a toda la arquitectura de

software y puede combinarse en la propuesta de solución.

61

http://es.wikipedia.org/wiki/Cliente-servidor

http://es.wikipedia.org/wiki/Arquitectura_de_tres_niveles

Patrón arquitectónico: se enfoca a dar solución a un problema en específico, de un

atributo de calidad y abarca solo parte de la arquitectura.

.

Patrón de diseño: ayuda a diseñar la estructura interna de un componente específico, es

decir, su detalle.

Un aspecto importante en el diseño de la arquitectura es que los atributos de calidad

establecidos, determinan los estilos arquitectónicos que pueden ser utilizados o adoptados,

en tanto pueden contribuir o afectar el logro de dichos atributos de calidad.

2.7.4 Definición de vistas.

Otro elemento importante dentro de la arquitectura de software es que debe definirse a

través de vistas, que representan las diferentes perspectivas del diseño, dichas vistas

pueden representarse mediante lenguajes de modelado, como UML, esta definición debe

documentarse de manera completa, incluyendo toda la explicación de su diseño, es decir, lo

que se ha representado gráficamente, así como las justificaciones de porqué se llegó, fue

mejor o se omitieron partes de la propuesta de solución.

De la misma manera que existe un documento de especificación de requerimientos de

software, se debe crear un documento de la arquitectura de software del sistema deseado,

que servirá para generar el diseño detallado de dicho sistema.

Un vez generada y documentada la arquitectura de software, ésta debe evaluarse para

verificar que cumpla con todos los requerimientos; específicamente con los atributos de

calidad establecidos, dicha evaluación puede realizarse mediante técnicas cualitativas,

como cuestionarios o escenarios, o a través de técnicas cuantitativas, como simulaciones o

modelos matemáticos.

De manera general, se puede decir que las tareas realizadas para el desarrollo de una

arquitectura de software son: identificación de los requerimientos arquitectónicos, diseño

62

de la arquitectura, documentación de la arquitectura, evaluación de la arquitectura, y

validación de la arquitectura con los diferentes interesados en el sistema que se encuentre

en desarrollo.

Se concluye entonces que el diseño de una arquitectura de software debe considerarse una

parte fundamental, crítica e imprescindible en el desarrollo de un sistema de software, ya

que es precisamente en esta fase en donde recae toda la creatividad, experiencia y creación

de la propuesta de solución que más se adecue a las necesidades del cliente permitiendole

lograr sus objetivos.

2.8 Implementación.

Ya conociendo la funciones que debe desempeñar el sistema de información (análisis) y

haber decidido cómo se va a organizar sus distintos componentes (diseño), es el momento

de pasar a la etapa de implementación. Antes de escribir una sola línea de código (o de

crear una tabla en nuestra base de datos) es fundamental haber comprendido bien el

problema que se pretende resolver y haber aplicado principios básicos de diseño que

permitan construir un sistema de información de calidad.

Para la fase de implementación hay que seleccionar las herramientas adecuadas, un entorno

de desarrollo que facilite el trabajo y un lenguaje de programación apropiado para el tipo de

sistema que se desea construir. La elección de estas herramientas dependerá en gran parte

de las decisiones de diseño que se hayan tomado hasta el momento y del entorno en el que

el sistema deberá funcionar.

A la hora de programar, procurar que el código no resulte indescifrable. Para que este sea

legible, hay que evitar sentencias de control no estructuradas, elegir cuidadosamente los

identificadores de las variables, seleccionar algoritmos, estructuras de datos adecuadas,

clases y objetos a desarrollar, mantener la lógica de la aplicación lo más sencilla posible,

comentar adecuadamente el texto de los programas y por último, facilitar la interpretación

63

visual del código mediante el uso de sangrías y líneas en blanco que separen distintos

bloques de código.

Además de las tareas de programación asociadas a los distintos componentes del sistema,

en la fase de implementación también hay que encargarse de la adquisición de todos los

recursos necesarios para que el sistema funcione (por ejemplo, las licencias de uso del

sistema gestor de bases de datos a utilizar). Usualmente, también se desarrollan algunos

casos de prueba que permitan ir comprobando el funcionamiento del software conforme se

va construyendo.

2.8.1 Diseño de las bases de datos.

Podemos definir a una base de datos, como un archivo en el cual se almacena información

de cualquier tipo. En dicho archivo la información se almacena en campos (columnas) o

delimitadores, es decir, se puede almacenar el nombre y el apellido de las personas de

modo separado, de esta forma podemos sacar del archivo todos los nombres o todos los

apellidos, tanto de forma separada como de forma conjunta o como se muestra en la figura

podemos tener el nombre y apellidos en una sola columna. A el conjunto de estos campos

se le conoce como registros o filas.

Código Nombre Posición Salario

1 Edgar Trujillo Gerente 19000

2 Lidimarie Fonsi Empleada 12000

3 Jean Piaget Empleado 13500

4 Jerome Bruner Empleado 14000

Código Nombre Posición Salario

1 Edgar Trujillo Gerente 19000

2 Lidimarie Fonsi Empleada 12000

3 Jean Piaget Empleado 13500

4 Jerome Bruner Empleado 14000

Fila

ColumnaNombre de la tabla : Trabajo

Figura 2.20 Tabla de una base de datos.

64

Normalmente el número de campos que se puede tener en una base varía según las

necesidades en cuanto a separación de datos, de forma que, después se pueda obtener la

información de forma ordenada y separada, aunque el resto de la información sigue

almacenada y guardada en la base de datos.

Aunque en realidad hay que tener en cuenta, que una base de datos, no es solo el archivo

en donde guardamos la información, sino que, en dicho archivo se encuentra la estructura

de los datos, es decir los atributos de cada campo, nombre, longitud, tipo de dato a

almacenar.

El diseño de una base de datos es un proceso complejo que abarca decisiones a muy

distintos niveles. La complejidad se controla mejor si se descompone el problema en

subproblemas y se resuelve cada uno de estos independientemente, utilizando técnicas

específicas. Así, el diseño se descompone en diseño conceptual, diseño lógico y diseño

físico.

El diseño conceptual parte de las especificaciones de requisitos de usuario y su resultado es

el esquema conceptual de la base de datos. Un esquema conceptual es una descripción de

alto nivel de la estructura de la base de datos, independientemente del SGBD13 que se vaya

a utilizar para manipularla. Un modelo conceptual es un lenguaje que se utiliza para

describir esquemas conceptuales. El objetivo de este tipo de diseño es describir el contenido

de información de la base de datos y no las estructuras de almacenamiento que se

necesitarán para manejar esta información.

El diseño lógico parte del esquema conceptual y da como resultado un esquema lógico que

es una descripción de la estructura de la base de datos en términos de las estructuras de

datos que puede procesar un tipo de SGBD.

13 SGBD. Ver glosario.

65

El diseño lógico depende del tipo de SGBD que se vaya a utilizar, no depende del producto

concreto.

El diseño físico parte del esquema lógico y da como resultado un esquema físico. Un

esquema físico es una descripción de la implementación de una base de datos en memoria

secundaria: las estructuras de almacenamiento y los métodos utilizados para tener un acceso

eficiente a los datos. Por ello, el diseño físico depende del SGBD concreto y el esquema

físico se expresa mediante su lenguaje de definición de datos.

El Modelo Conceptual de Datos es independiente del software de gestión de bases de datos

utilizado. Para proceder al diseño de los ficheros y de las bases de datos del sistema, se

debe convertir previamente el modelo conceptual que incluía tipos de entidades y

relaciones con atributos asociados, en un modelo lógico que únicamente considere tipos de

registros compuestos por campos de datos. Al modelo lógico de datos normalmente se le

suele llamar diagrama de estructura de datos (DED) o Diagrama de Bachman.

Existen tres tipos de SGBD. Basados en una base de datos relacional, en el que se

almacenan los datos como un conjunto de tablas o relaciones. Basados en una base de

datos en red, en el que la estructura de los registros establece una relación subordinada

"padre-hijo" entre ellos. (p.ej., n registro departamento puede poseer registros proyectos

que, a su vez, poseen registros empleados). Basados en una base de datos jerárquica,

similar a la anterior, con la diferencia que cada registro sólo puede tener un padre. Nos

limitaremos a las basadas en bases de datos relacionales, ya que son las más utilizadas y

poseen la ventaja de que la conversión del modelo conceptual es directa, sin más que

considerar las entidades como registros y los atributos como campos de éstos.

2.8.1.1 Cualidades de un buen diseño de base de datos.

• Reflejar la estructura del problema en el mundo real.

• Ser capaz de representar todos los datos esperados, incluso con el paso del tiempo.

• Evitar el almacenamiento de información redundante.

66

• Proporcionar un acceso eficaz a los datos.

• Mantener la integridad de los datos a lo largo del tiempo.

• Ser claro, coherente y de fácil comprensión.

Nota: A veces, estos objetivos pueden ser contradictorios.

2.8.1.2 El modelo relacional.

• Todos los datos se representan en tablas.

Incluso los resultados de cualquier consulta son otra tabla.

• Las tablas están compuestas por filas y columnas.

• Las filas y las columnas, en principio, carecen de orden (p.ej., el orden en el que se

muestren las filas y las columnas no importa).

Las filas sólo se ordenan si se le indica a la base de datos que lo haga, mediante el

correspondiente comando. De no ser así, el orden será arbitrario, y puede cambiar

en caso de tratarse de una base datos dinámica.

El orden de las columnas lo determina cada consulta.

2.8.1.2.1 Estructura del modelo relacional.

Clave Primaria: es el atributo o grupo de atributos que identifica a la tabla. No puede haber

dos o más registros en una tabla con el mismo valor en el campo clave.

Clave Candidata o Alternativa: una posible clave principal.

Clave Ajena: atributo o conjunto de atributos cuyo valor debe coincidir con el valor de la

clave primaria de algún registro de la relación R a la cual hace referencia.

Restricción de clave: los valores de las claves candidatas deben ser únicos para cada

registro en cualquier caso de la tabla.

67

Restricción de integridad de entidades: ningún valor de la clave primaria puede ser nulo.

Restricción de integridad referencial: se especifica entre dos tablas o relaciones y se usa

para mantener la consistencia entre las tablas relacionadas. Establece que un registro de una

tabla que haga referencia a otra tabla, debe referirse a un registro existente en esa tabla.

El esquema lógico es un conjunto de tablas en el cual, cada tabla tiene un identificador. Se

trata de pasar del DER al esquema lógico correspondiente, para lo que se tendrá que

realizar una transformación para las entidades y otra para las relaciones del DER. Para

cada entidad del DER se obtendrá una tabla con tantos campos como atributos tenga. Esta

transformación es directa. Para las relaciones N:N es necesario crear una nueva tabla,

mientras que el resto de relaciones puede ser modelada añadiendo atributos a las tablas

existentes.

2.8.1.2.2 Transformación de relaciones 1:1.

Sean dos entidades, E1 y E2 relacionadas entre sí por una relación R de tipo 1:1. En

principio, tanto E1 como E2 producen tablas individuales. En cuanto a la relación, se tiene

que estudiar el comportamiento de las entidades E1 y E2 .

Si las dos entidades participan de forma total y tienen las mismas claves primarias, se

fusionan en una única tabla formada por los campos de ambas e incluyendo la clave

primaria una sola vez.

Si las dos entidades tienen claves primarias diferentes, se fusionan en una única tabla

formada por los campos de ambas. Una de las dos claves primarias es la clave primaria de

la tabla resultante.

Cuando una de las entidades participa de forma parcial en la relación, se obtiene una nueva

tabla para la relación, en la que aparecerán las claves principales de las entidades

participantes.

68

2.8.1.2.3 Transformación de relaciones 1:N.

Sean dos entidades, E1 y E2 relacionadas entre sí por una relación R de tipo 1:N.

Si la entidad del lado de "muchos" participa de forma obligatoria, la clave primaria de la

entidad del lado de "uno" se debe incluir en la tabla del lado de "muchos".

Si la entidad del lado de "muchos" tiene una participación parcial, se establece una nueva

tabla formada por las claves primarias de las entidades y como clave primaria, la clave de la

tabla del lado obligatorio.

2.8.1.2.4 Transformación de relaciones N:N.

Sean dos entidades, E1 y E2 relacionadas entre sí por una relación R de tipo 1:N. En este

caso, se crea una nueva tabla que tiene como clave primaria la combinación de atributos

que constituyen las claves primarias tanto de E1 como E2 y que incluye los atributos de R.

2.8.1.3 Modelo Entidad/Interrelación (E/R).

• El modelo Entidad/Interrelación (E/R): un método de diseño de bases de datos.

• Muestra de una versión simplificada.

• Representa los datos mediante una serie de entidades que disponen de atributos.

• Una entidad es una clase de objetos o conceptos claramente identificable.

• Las entidades establecen interrelaciones con otras entidades.

• El resultado de este proceso es una base de datos normalizada que facilita el acceso a los

datos y evita su duplicado.

Nota: en su mayor parte, el diseño formal de una base de datos se centra en la

normalización de la base y en asegurar que el diseño se ajuste a un nivel de normalización

(p.ej., first normal form, second normal form, etc.). Este nivel de formalidad va mucho más

allá, pero es importante saber que existen tales formalidades.

69

2.8.1.3.1 Proceso de diseño en el modelo E-R.

• Identificar las entidades que debe presentar la base de datos.

• Determinar las cardinalidades14 de las interrelaciones establecidas entre las distintas

entidades y clasificar estas interrelaciones entre los siguientes tipos:

Uno a uno (p.ej., una parcela sólo tiene una dirección).

Uno a muchos (p.ej., en una parcela pueden ocurrir varios incendios).

Muchos a muchos (p.ej., la venta de parcelas: una misma parcela la pueden vender

varios propietarios y cada propietario puede vender varias parcelas). Ver tabla 2.2.

• Dibujar el diagrama Entidad/Interrelación.

• Determinar los atributos de cada entidad.

• Definir la clave primaria (única) de cada entidad.

Tabla 2.2 Tipos de relaciones.

TIPO RELACIÓN REPRESENTACIÓN

1:1

1 1 Una a una : La cardinalidad máxima en ambas direcciones es 1.

1:N

Una a muchas: La cardinalidad

máxima en una dirección es 1 y en la otra muchos.

1 N

N:M

Muchas a muchas: La cardinalidad máxima en ambas direcciones en

muchos.

N M

2.8.1.4 Normalización.

• El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a

las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional. 14 Cardinalidades. Ver glosario

70

• Las bases de datos relacionales se normalizan para:

Evitar la redundancia de los datos.

Evitar problemas de actualización de los datos en las tablas.

Proteger la integridad de los datos.

• En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una

tabla sea considerada como una relación tiene que cumplir con algunas restricciones:

• Cada columna debe tener su nombre único.

• No puede haber dos filas iguales. No se permiten los duplicados.

• Todos los datos en una columna deben ser del mismo tipo.

La normalización es el proceso mediante el cual se transforman datos complejos a un

conjunto de estructuras de datos más pequeñas, que además de ser más simples y más

estables, son más fáciles de mantener. También se puede entender la normalización como

una serie de reglas que sirven para ayudar a los diseñadores de bases de datos a desarrollar

un esquema que minimice los problemas de lógica. Cada regla está basada en la que le

antecede.

La normalización se adoptó porque el viejo estilo de poner todos los datos en un solo lugar,

como un archivo o una tabla de la base de datos, era ineficiente y conducía a errores de

lógica cuando se trataban de manipular los datos. La normalización también hace las cosas

fáciles de entender. Los seres humanos tenemos la tendencia de simplificar las cosas al

máximo. Lo hacemos con casi todo, desde los animales hasta con los automóviles. Vemos

una imagen de gran tamaño y la hacemos más simple agrupando cosas similares juntas. Las

guías que la normalización provee crean el marco de referencia para simplificar una

estructura de datos compleja.

Otra ventaja de la normalización de base de datos es el consumo de espacio. Una base de

datos normalizada ocupa menos espacio en disco que una no normalizada. Hay menos

repetición de datos, lo que tiene como consecuencia un mucho menor uso de espacio en

disco.

71

El proceso de normalización tiene un nombre y una serie de reglas para cada fase. Esto

puede parecer un poco confuso al principio, pero poco a poco se va entendiendo el proceso,

así como las razones para hacerlo de esta manera.

2.8.1.4.1 Grados de normalización.

Existen básicamente tres niveles de normalización: Primera Forma Normal (1NF), Segunda

Forma Normal (2NF) y Tercera Forma Normal (3NF). Cada una de estas formas tiene sus

propias reglas. Cuando una base de datos se conforma a un nivel, se considera normalizada

a esa forma de normalización. No siempre es una buena idea tener una base de datos

conformada en el nivel más alto de normalización, puede llevar a un nivel de complejidad

que pudiera ser evitado si estuviera en un nivel más bajo de normalización.

En la tabla siguiente se describe brevemente en qué consiste cada una de las reglas.

Tabla 2.3 Formas de normalización.

Regla Descripción

Primera Forma Normal (1FN) Incluye la eliminación de todos los grupos repetidos.

Asegura que todas las columnas que no son llave

sean completamente dependientes de la llave

primaria (PK).

Segunda Forma Normal (2FN)

Elimina cualquier dependencia transitiva. Una

dependencia transitiva es aquella en la cual las

columnas que no son llave son dependientes de otras

columnas que tampoco son llave.

Tercera Forma Normal (3FN)

72

2.8.2 Codificación del software.

Durante esta la etapa se realizan las tareas que comúnmente se conocen como

programación; que consiste, esencialmente, en llevar a código fuente, en el lenguaje de

programación elegido, todo lo diseñado en la fase anterior. Esta tarea la realiza el

programador, siguiendo por completo los lineamientos impuestos en el diseño y en

consideración siempre a los requisitos funcionales y no funcionales (ERS) especificados en

la primera etapa.

Es común pensar que la etapa de programación o codificación (algunos la llaman

implementación) es la que insume la mayor parte del trabajo de desarrollo del software; sin

embargo, esto puede ser relativo (y generalmente aplicable a sistemas de pequeño porte) ya

que las etapas previas son cruciales, críticas y pueden llevar bastante más tiempo. Se suele

hacer estimaciones de un 30% del tiempo total insumido en la programación, pero esta cifra

no es consistente ya que depende en gran medida de las características del sistema, su

criticidad y el lenguaje de programación elegido. En tanto menor es el nivel del lenguaje

mayor será el tiempo de programación requerido, así por ejemplo se tardaría más tiempo en

codificar un algoritmo en ensamblador que el mismo programado en lenguaje C.

Mientras se programa la aplicación, sistema, o software en general, se realizan también

tareas de depuración, esto es la labor de ir liberando al código de los errores factibles de ser

hallados en esta fase (de semántica, sintáctica y lógica). Hay una suerte de solapamiento

con la fase siguiente, ya que para depurar la lógica es necesario realizar pruebas unitarias,

normalmente con datos de prueba; claro es que no todos los errores serán encontrados sólo

en la etapa de programación, habrá otros que se encontrarán durante las etapas

subsiguientes. La aparición de algún error funcional (mala respuesta a los requerimientos)

eventualmente puede llevar a retornar a la fase de análisis y diseño antes de continuar la

codificación.

Durante la fase de programación, el código puede adoptar varios estados, dependiendo de la

forma de trabajo y del lenguaje elegido, a saber:

73

• Código fuente: Es el escrito directamente por los programadores en editores de texto, lo

cual genera el programa. Contiene el conjunto de instrucciones codificadas en algún

lenguaje de alto nivel. Puede estar distribuido en paquetes, procedimientos, librerías

fuente, etc.

• Código objeto: Es el código binario o intermedio resultante de procesar con un

compilador el código fuente. Consiste en una traducción completa y de una sola vez

de éste último. El código objeto no es inteligible por el ser humano (normalmente es

formato binario) pero tampoco es directamente ejecutable por la computadora. Se

trata de una representación intermedia entre el código fuente y el código ejecutable, a

los fines de un enlace final con las rutinas de librería y entre procedimientos o bien

para su uso con un pequeño intérprete intermedio (compilador puro).

El código objeto no existe si el programador trabaja con un lenguaje a modo de

intérprete puro, en este caso el mismo intérprete se encarga de traducir y ejecutar

línea por línea el código fuente (de acuerdo al flujo del programa), en tiempo de

ejecución. En este caso tampoco existe el o los archivos de código ejecutable. Una

desventaja de esta modalidad es que la ejecución del programa o sistema es un

poco más lenta que si se hiciera con un intérprete intermedio es decir no favorece el

rendimiento en velocidad de ejecución. Pero una gran ventaja de la modalidad

intérprete puro, es que el esta forma de trabajo facilita enormemente la tarea de

depuración del código fuente (frente a la alternativa de hacerlo con un compilador

puro). Frecuentemente se suele usar una forma mixta de trabajo (si el lenguaje de

programación elegido lo permite), es decir inicialmente trabajar a modo de

intérprete puro y una vez depurado el código fuente (liberado de errores) se utiliza

un compilador del mismo lenguaje para obtener el código ejecutable completo, con

lo cual se agiliza la depuración y la velocidad de ejecución se optimiza.

• Código ejecutable: Es el código binario resultado de enlazar uno o más fragmentos de

código objeto con las rutinas y librerías necesarias. Constituye uno o más archivos

binarios con un formato tal que el sistema operativo es capaz de cargarlo en la

memoria RAM (eventualmente también parte en una memoria virtual), y proceder a

74

su ejecución directa. Por lo anterior se dice que el código ejecutable es directamente

"inteligible por la computadora". El código ejecutable, también conocido como

código máquina, no existe si se programa con modalidad de "intérprete puro".

2.8.3 Pruebas.

Consiste en comprobar que el software realice correctamente las tareas indicadas en la

especificación. Una técnica de prueba es probar por separado cada módulo del software, y

luego probarlo de forma integral, para así llegar al objetivo. Se considera una buena

practica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la

programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe

hacer sus propias pruebas. En general hay dos grandes formas de organizar un área de

pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema

de pruebas, de esta forma se evalúa que la documentación entregada sea de calidad, que los

procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las

cosas tal y como están descritas. El segundo enfoque es tener un área de pruebas

conformada por programadores con experiencia, personas que saben sin mayores

indicaciones en qué condiciones puede fallar una aplicación y que pueden poner atención

en detalles que personal inexperto no consideraría.

La prueba del software es un elemento crítico para la garantía de la calidad del software. El

objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,

esta etapa implica:

• Verificar la interacción de componentes.

• Verificar la integración adecuada de los componentes.

• Verificar que todos los requisitos se han implementado correctamente.

• Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el

software al cliente.

• Diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores,

haciéndolo con la menor cantidad de tiempo y esfuerzo.

75

Es una etapa del proyecto en la cual se asegura la calidad, debe ocurrir durante todo el ciclo

de vida: se puede probar la funcionalidad de los primeros prototipos; la estabilidad,

cobertura y rendimiento de la arquitectura; y el producto final, etc., es un proceso que se

enfoca sobre la lógica interna del software y las funciones externas. La prueba es un

proceso de ejecución de un programa con la intención de descubrir un error. Un buen caso

de prueba es aquel que tiene alta probabilidad de mostrar un error no descubierto hasta

entonces, esta no puede asegurar la ausencia de defectos; sólo puede demostrar que existen

defectos en el software.

Cualquier proceso de ingeniería puede ser probado de una de dos formas:

• Se pueden llevar a cabo pruebas que demuestren que cada función es completamente

operativa.

• Se pueden desarrollar pruebas que aseguren que la operación interna se ajusta a las

especificaciones y que todos los componentes internos se han comprobado de forma

adecuada.

La primera aproximación se denomina prueba de la caja negra y la segunda prueba de la

caja blanca.

2.8.3.1 Prueba de caja blanca.

Permiten examinar la estructura interna del programa. Se diseñan casos de prueba para

examinar la lógica del programa. Es un método de diseño de casos de prueba que usa la

estructura de control del diseño procedimental para derivar casos de prueba que garanticen

que:

• Se ejercitan todos los caminos independientes de cada módulo.

• Se ejercitan todas las decisiones lógicas.

• Se ejecutan todos los bucles.

76

• Se ejecutan las estructuras de datos internas.

2.8.3.2 Prueba de caja negra.

Las pruebas se llevan a cabo sobre la interfaz del software es completamente indiferente el

comportamiento interno y la estructura del programa.

Los casos de prueba de la caja negra pretende demostrar que:

• Las funciones del software son operativas.

• La entrada se acepta de forma adecuada.

• Se produce una salida correcta y

• La integridad de la información externa se mantiene.

Se derivan conjuntos de condiciones de entrada que ejerciten completamente todos los

requerimientos funcionales del programa.

La prueba de la caja negra intenta encontrar errores de las siguientes categorías:

• Funciones incorrectas o ausentes.

• Errores de interfaz.

• Errores en estructuras de datos o en accesos a bases de datos externas.

• Errores de rendimiento.

• Errores de inicialización y de terminación.

Los casos de prueba deben satisfacer los siguientes criterios:

• Reducir, en un coeficiente que es mayor que uno, el número de casos de prueba

adicionales.

• Que digan algo sobre la presencia o ausencia de clases de errores.

77

2.8.4 Mantenimiento.

Con posterioridad a la fase de implementación de los sistemas, se impone la fase de

mantenimiento. El mantenimiento de sistemas es el mantenimiento continuo después del

inicio del funcionamiento.

Cuando se elaboran planes para la estrategia de información, las organizaciones no pueden

dejar de considerar que el mantenimiento de sistemas es la fase más prolongada y costosa

del ciclo de vida de los sistemas. Las implicaciones del volumen de trabajo para

mantenimiento para los planes de estrategia de información en una organización es un tema

que merece atención especial. La estructura de organización necesita flexibilidad para

apoyar el mantenimiento de los sistemas existentes concurrentemente con la ejecución de

nuevas tecnologías.

Es importante considerar la evaluación y el monitoreo de un sistema en términos del

mantenimiento necesario y en consecuencia, reducir o contener los costos implícitos. El

mantenimiento de sistemas puede clasificarse en cuatro grupos, cada uno de los cuales

repercute en el plan estratégico de información institucional de diferentes maneras:

• Mantenimiento correctivo. Independientemente de cuán bien diseñado, desarrollado y

probado está un sistema o aplicación, ocurrirán errores inevitablemente. Este tipo de

mantenimiento se relaciona con la solución o la corrección de problemas del sistema.

Atañe generalmente a problemas no identificados durante la fase de ejecución. Un

ejemplo de mantenimiento correctivo es la falta de una característica requerida por el

usuario, o su funcionamiento defectuoso.

• Mantenimiento para fines específicos. Este tipo de mantenimiento se refiere a la

creación de características nuevas o a la adaptación de las existentes según lo

requieren los cambios en la organización o los usuarios, por ejemplo, los cambios en

el código tributario o los reglamentos internos de la organización.

• Mantenimiento perfectivo. Se trata de la extensión o el mejoramiento del desempeño del

sistema, ya sea mediante el agregado de nuevas características, o el cambio de las

78

existentes. Un ejemplo de este tipo de mantenimiento es la conversión de los sistemas

de texto a GUI (interfaz gráfica de usuarios).

• Mantenimiento preventivo. Este tipo de mantenimiento es probablemente uno de los más

eficaces en función de los costos, ya que si se realiza de manera oportuna y adecuada,

puede evitar serios problemas en el sistema. Un ejemplo de este mantenimiento es la

corrección del problema del año 2000.

2.8.4.1 Mantenibilidad.

Con este término, que aunque inexistente en el léxico español se ha hecho hueco en nuestra

jerga, se define una propiedad del software que se puede definir como: la medida

cualitativa de la facilidad para comprender, corregir y adaptar o mejorar el software.

Los factores que conforman la mantenibilidad de un sistema de software son:

• Mayor o menor profesionalidad en las fases de diseño, codificación y prueba.

• Adecuada cualificación del equipo desarrollador del software.

• Facilidad de comprensión de la estructura del software.

• Facilidad de uso del sistema.

• Uso de lenguajes de programación y sistemas operativos estandarizados.

• Grado de normalización de la documentación.

• Disponibilidad de la documentación de los casos de prueba.

• Facilidades de depuración con las que cuenta el sistema.

• Disponibilidad de medios e infraestructura para realizar el mantenimiento.

• Madurez en la planificación del mantenimiento.

2.8.4.2 Reingeniería del software.

El modelo comprende 6 actividades. La primera es un análisis de inventario del que se

decidirá si se aplica reingeniería, en caso afirmativo se emplearán alguna o todas de las

cinco actividades restantes:

79

• Análisis de inventario.

El inventario del sistema comprende la información necesaria para el análisis que

servirá para decidir si resulta más conveniente rehacer de nuevo el sistema, o

aplicar técnicas de reingeniería.

• Reestructuración de documentos.

Los sistemas en los que se cuestiona aplicar reingeniería suelen tener deficiencias

en su documentación.

En función de las características del proyecto, tras el análisis del inventario las

opciones son: dejarlo como está porque se trata de un sistema con escasa previsión

de cambios futuros. También porque se trata de un sistema que se encuentra

cercano al fin de su ciclo de vida y finalmente porque los recursos necesarios para

crear la documentación no compensan con el beneficio obtenido.

Documentar sólo las partes que se modifican debido a que se dispone de recursos

limitados y tras el análisis de inventario resulta necesario actualizar la

documentación.

Reducir la documentación al mínimo ya que se trata de un sistema crítico para el

negocio o porque es preciso volver a documentarlo.

• Ingeniería inversa.

La ingeniería inversa realiza un análisis de un sistema de software para conseguir

especificar su documentación; generalmente su diseño.

Obviamente se aplica cuando no se dispone del diseño, o éste está obsoleto.

Un proceso de ingeniería inversa debe ser capaz de derivar las representaciones de

diseño de procedimientos, debe extraer la estructura de datos, representar el modelo

de los flujos de datos, de control y finalmente representar el modelo de entidad y

relación.

• Reestructuración de código.

Los sistemas que tras un análisis de inventario quedan como candidatos a una

reestructuración de código suelen presentar una arquitectura de programa

80

relativamente sólida, pero presentan módulos individuales que por haber sufrido

modificaciones poco ortodoxas, o por las razones que sean presentan un código

“sucio” de difícil comprensión, comprobación y mantenibilidad.

• Reestructuración de datos.

Las deficiencias en las estructuras de datos son una de las principales causas de

errores.

Es necesario realizar reestructuración (rediseño y posterior migración de la

información al nuevo diseño) en las bases de datos que por no tener un diseño

normalizado, o sin integridad relacional presentan un riesgo de error cuyo impacto

aconseje su reestructuración.

La reestructuración de datos suele implicar también modificaciones de código.

• Reingeniería progresiva.

Por el estado actual de las herramientas CASE se trata de un modelo ideal de

proceso, más que de un proceso que se pueda aplicar directamente.

Su objetivo es ejecutar ingeniería inversa y reestructuración de código de forma

automática a través de herramientas CASE que analicen el código y generen su

diseño, así como su reestructuración.

81

Capítulo III.- Análisis, diseño e implementación de la aplicación

sugerida.

Se sugiere crear un sistema de información que permita aplicar exámenes o evaluaciones

escolares, de capacitación y corporativos con opción a encuestas de una manera sencilla y

rápida a través de una red pública como Internet o de una VPN.

En diferentes países que cuentan con tecnología de punta existen sistemas de evaluación en

línea, en nuestro país únicamente algunas empresas y universidades que cuentan con la

plataforma e-learning15 pueden realizar exámenes a través de Internet, sin embargo no

existe registro de una aplicación dedicada exclusivamente a la evaluación.

Con esta aplicación cualquier escuela o institución que cuente con un hospedaje web, podrá

aplicar a sus educandos, trabajadores y colaboradores evaluaciones a distancia, sin la

necesidad de tener contacto presencial con las personas.

Las plataformas e-learnig cuentan con esta opción, sin embargo requieren de una

infraestructura docente para llevarla a cabo. El sistema sugerido SEECONLINE (Sistema

de Exámenes Escolares y Corporativos En Línea) podrá auxiliar a cualquier institución que

requiera de evaluar a distancia y que su capacitación sea presencial.

15 e-larning. Ver Glosario

82

3.1 Análisis.

En base a los requerimientos generales y específicos se permite documentar que

SEECONLINE debe contar con las siguientes características:

• El sistema podrá realizar diferentes tipos de exámenes:

Opción múltiple.

Falso-verdadero.

Respuestas abiertas.

Encuestas.

• Para fines de este proyecto se dejará estructurado para contemplar los tipos anteriores y

se implementará en su fase inicial exámenes de opción múltiple.

• Permitirá asignar un valor en puntos a cada una de las preguntas.

• Podrá editar (añadir, eliminar o cambiar) en cualquier momento las preguntas para cada

examen.

• Asignará un número determinado de intentos para cada examen.

• Permitir el acceso diferenciado de los usuarios según su nivel de responsabilidad para la

realización de una tarea. Utilizaremos encriptación en el nombre de usuario y

passwords correspondientes.

• Los usuarios con privilegios de administración tendrán acceso a las opciones de creación

de grupos, alumnos, grupos, exámenes y administración de reportes de calificaciones.

• El administrador o supervisor podrá elaborar exámenes de diferentes tipos; para fines del

proyecto de tesis, la aplicación operará con exámenes del tipo opción múltiple,

teniendo la capacidad de poderse ampliar en otra versión a fin de aplicar diferentes

tipos de evaluaciones, incluyendo encuestas.

• Las tareas que podrá ejecutar el administrador:

Desarrollar n exámenes con n número de preguntas.

Cada pregunta tendrá un mismo número posible de respuestas de opción múltiple.

El número de opciones posibles las podrá definir el administrador

Creará grupos de usuarios.

Creará y dará mantenimiento a los usuarios.

83

Asignará y cancelará exámenes a grupos o a usuarios individuales.

Asignará fechas y tiempo limite a los diferentes exámenes.

Asignará porcentaje y/o calificación a cada pregunta.

• La mayoría de las personas (alumnos) que accederán al sistema únicamente podrán

utilizarlo para aplicarse una evaluación, sin posibilidad de otras opciones.

• Las funciones que podrá ejecutar el usuario son:

Solicitar contacto vía e-mail.

Aplicar exámenes o encuestas en las fechas y tiempos permitidos por el

administrador o supervisor (profesor).

• El sistema contará con un editor de textos sencillo donde escribirá las preguntas con la

posibilidad futura de insertar imágenes en las mismas.

• Inicialmente tendrá una clave de administrador universal, misma que se podrá modificar

por el administrador en turno.

• Dará mantenimiento a supervisores (profesores), administradores y a aplicandos

(alumnos).

• Creará reportes individuales y por grupo del resultado de las evaluaciones.

El sistema se recomendamos se ha basado en funcionalidades de diversas plataformas que

existen en el mercado de uso libre como Moodle16, TCExam, Unitest.

Debido al uso popular y de conocimiento que han tenido las diversas plataformas podremos

implementar un sistema que cumpla con las necesidades básicas para aplicar preguntas de

evaluación, contemplando la implementación, en base a la Ingeniería del Software.

16 Moodle es un sistema de gestión de cursos de libre distribución que ayuda a los educadores a crear comunidades de aprendizaje en

línea.

84

3.2 Diseño.

El propósito de esta documentación es el de especificar los requerimientos funcionales y no

funcionales del sistema SEECONLINE, de tal manera que sirva como documento guía al

desarrollar el software y que este cumpla las características convenidas con el usuario.

Las funcionalidades del SEECONLINE estarán orientadas en:

• La administración y acceso a las diferentes opciones de gestión del sistema.

• Actualización constante de la información relacionada al SEECONLINE.

• Realización de exámenes en línea y con tiempo.

Las funcionalidades que no incluye el SEECONLINE son:

• Implementar capacitación a distancia.

• Administración del sitio web.

• Comunicación vía chats o en tiempo real entre usuarios.

El SEECONLINE se aplicará a cualquier nivel, será destinada para cualquier, escuela,

empresa o negocio proporcionando una nueva elaboración y aplicación de exámenes en

línea.

3.2.1 Descripción general de interfaces.

Se refiere al ambiente en que operará el sistema y no al ambiente del desarrollo del mismo.

3.2.1.1 Interfaces del sistema.

Estarán basadas en un ambiente gráfico para que puedan ser vistas a través de cualquier

explorador de Internet.

El sistema es independiente y no tiene relación con otros sistemas para ningún proceso.

85

3.2.1.2 Interfaz de usuario y patrones arquitectónicos.

Dependiendo del nivel de usuario, automáticamente aparecerán las opciones de las cuales

pueda disponer, en un ambiente amigable, estable que le permita intuir la fácil operación

del sistema. Como la aplicación será desarrollada y operada en un entorno visual, la

interacción entre la aplicación y el usuario se realizará mediante ventanas, formularios,

botones, etiquetas, listas, e íconos.

3.2.1.3 Interfaces de comunicación.

Debido a que el medio es a través de la Internet o una Intranet, se necesitará la instalación

de un servidor Apache17 con la herramienta de PHP y base de datos MySQL, todas ellas de

uso libre. Al implementarla en una VPN tendrá restricciones de acceso para los usuarios

permitidos

3.2.1.4 Interfaces de hardware.

Debido a que el sistema se podrá desarrollar en el lenguaje PHP que es un lenguaje de

servidor, es decir, la interpretación del código se realiza en el servidor y éste manda al

cliente (usuario final) las instrucciones ya compiladas únicamente el usuario final deberá

contar con una computadora personal que tenga acceso a Internet y que cuente con un

navegador sin importar la plataforma en la que esté trabajando.

3.2.1.5 Interfaces del software.

Utilizaremos WampServer 2.0 para soportar las herramientas necesarias para el desarrollo y

operación de SEECONLINE como Apache, MySQL, PHPmyAdmin y un editor de textos

para escribir y editar el código fuente. El administrador de la base de datos contará con

claves encriptadas (funciones que otorga PHPmyAdmin) para el mantenimiento de la

misma.

17 Apache. Servidor que utiliza el protocolo HTTP de uso libre.

86

3.3 Modelo.

El modelo estará basado en una combinación del modelo “Desarrollo basado en

reutilización”, combinado con el modelo espiral, ya que tomando como referencia que

existen en el mercado (no en español), diversos programas con código abierto y que este se

puede reutilizar hasta llegar a una mejor integración y robustez. Además con los

requerimientos de crecimiento e integración que existen por parte de escuelas y negocios,

es necesario complementar e implementar nuevas funcionalidades al sistema.

3.4 Metodología.

De las diversas metodologías que existen consideramos que la combinación de algunas nos

resulta muy práctico aplicar diversos factores de cada una de ellas.

La metodología estructurada de la cual hemos establecido la formación de cada una de las

opciones que contendrá el sistema, para su mayor facilidad y entendimiento de la interfaz.

Parte de la programación será reutilizable para este y futuros proyectos, por ello se utilizará

el principio de la programación orientada a objetos, asimismo las metodologías ágiles las

contemplamos para ir trabajando en módulos que se van incrementando e implementando,

en cada una de las funciones que contemplará el proyecto.

3.5 Modelado. Para expresar gráficamente las partes del desarrollo del sistema se utilizo el lenguaje de

modelado UML, reflejado en las figuras 3.1 diagrama de caso de uso del administrador y de

usuario, a fin de observar el comportamiento y la interacción del usuario con el sistema se

realizo el modelado de las figura 3.2, y 3.3 diagrama de estados y colaboración

respectivamente.

87

Figura 3.1 Diagrama de caso de uso de administrador y de usuario.

Figura 3.2 Diagrama de estados.

88

Figura 3.3 Diagrama de colaboración.

3.6 Programación.

Al requerir desarrollar una aplicación que pueda ser vista a distancia, a través de una red

pública o privada, tenemos que utilizar un lenguaje que cubra estas necesidades, debido a

las bondades de código abierto y herramienta de uso libre así como su facilidad de uso y

robustez, proponemos programar y reutilizar código del lenguaje PHP.

PHP es un lenguaje de programación interpretado, diseñado originalmente para la creación

de páginas web dinámicas. Es usado principalmente en interpretación del lado del servidor

(server-side scripting) pero actualmente puede ser utilizado desde una interfaz de línea de

comandos o en la creación de otros tipos de programas incluyendo aplicaciones con interfaz

gráfica.

PHP es un acrónimo recursivo que significa PHP Hypertext Pre-processor (inicialmente

PHP Tools, o, Personal Home Page Tools). Fue creado originalmente por Rasmus Lerdof

en 1994; sin embargo la implementación principal de PHP es producida ahora por The PHP

Group y sirve como el estándar de facto para PHP al no haber una especificación formal.

Publicado bajo la PHP License, la Free Software Foundation considera esta licencia como

software libre.

89

PHP es un lenguaje de propósito general ampliamente usado y que está diseñado

especialmente para desarrollo web y puede ser embebido dentro de código HTML.

Generalmente se ejecuta en un servidor web, tomando el código en PHP como su entrada y

creando páginas web como salida. Puede ser desplegado en la mayoría de los servidores

web y en casi todos los sistemas operativos y plataformas sin costo alguno. Es también el

módulo Apache más popular entre las computadoras que utilizan Apache como servidor

web. La más reciente versión principal del PHP fue la versión 5.2.6 de 1 de mayo de 2008.

Además al proponer este lenguaje podremos contribuir al enriquecimiento de plataformas,

que como Moodle (creado en PHP), pueda ser reutilizado libremente.

3.6.1 Base de datos.

Al hablar del desarrollo de una aplicación de estas características es imprescindible utilizar

una base de datos como medio de almacenamiento, el modelo de tres capas nos permitiría

tener en una capa la interfaz de usuario, en otra la de la aplicación y en otra la de

almacenamiento (base de datos), sin embargo debido al número de transacciones que se

llevarán a cabo en el sistema la base de datos podrá ser almacenada en el mismo servidor

web en que se encuentre la aplicación, lo cual asimila al modelo cliente/servidor.

La base de datos constará de diversas tablas, donde se almacenarán los registros, de

usuarios, operarios, grupos de usuarios, clasificación de usuarios, preguntas de exámenes,

escalas de respuestas, resultados de exámenes, calificaciones.

Todas las tablas estarán normalizadas, en base a la estructura de bases de datos relacionales

y toda la base de datos contará con niveles de acceso, usuarios y passwords encriptados,

considerando los tres elementos de la seguridad, confidencialidad, integridad y

disponibilidad.

90

Debido a la robustez de acuerdo a la cantidad de transacciones a utilizar, uso libre y

excelente vinculación con el servidor Apache y el lenguaje PHP, proponemos utilizar el

gestor de base de datos MySQL.

91

Capítulo IV.- Implementación de la aplicación en una red

virtual privada (VPN).

4.1 Definición VPN.

VPN (Virtual Private Network) es una extensión de una red local y privada que utiliza

como medio de enlace una red pública por ejemplo, Internet.

Este método permite enlazar dos o más redes simulando una única red privada permitiendo

así la comunicación entre computadoras como si fuera punto a punto (ver figura 4.1).

También un usuario remoto se puede conectar individualmente a una LAN utilizando una

conexión VPN y de esta manera utilizar aplicaciones, enviar datos, etc. de manera segura.

Las Redes Privadas Virtuales utilizan tecnología de túnel (tunneling) para la transmisión de

datos mediante un proceso de encapsulación y en su defecto de encriptación, esto es

importante a la hora de diferenciar Redes Privadas Virtuales y Redes Privadas, ya que esta

ultima utiliza líneas telefónicas dedicadas para formar la red.

Esta tecnología es muy útil para establecer redes que se extienden sobre áreas geográficas

extensas, por ejemplo diferentes ciudades, países y continentes, o en empresas que tienen

oficinas remotas en puntos distante, la idea de implementar una VPN haría reducir

notablemente los costos de comunicación, dado que las llamadas telefónicas (en caso de

usar dial-up) serian locales(al proveedor de Internet) o bien utilizar conexiones DSL15, en

tanto que de otra manera habría que utilizar líneas dedicadas las cuales son muy costosas o

hacer tendidos de cables que serian más costosos aun.

92

Figura 4.1 Diagrama lógico.

4.2 Ventajas de una VPN.

Las VPN permiten la conexión segura a redes corporativas, a través de dispositivos móviles

como pueden ser: laptop, PDA,18 teléfonos celulares, dentro de este tipo de VPN’s se debe

considerar la tasa de transferencia y capacidad de procesamiento por parte de los equipos,

la mayor ventaja de las VPN es la conectividad y la movilidad para los usuarios finales.

Cuando se implementa una VPN, hay cuatro aspectos fundamentales que deben ser

considerados: costo, desempeño, confianza y seguridad de estas cuatro características, la

seguridad es el elemento fundamental ya que sin ésta los otros elementos pueden ser

inútiles; no importa qué tan barata, rápida y confiable sea una red, sin la seguridad

adecuada, los riesgos pesarán más que los beneficios. Una compañía puede usar la Internet

para enviar archivos a otras corporaciones; sin embargo, sin medidas y políticas de

seguridad adecuadas, la información queda expuesta a ataques. Provee de encriptación y

encapsulación de datos de manera que hace que estos viajen codificados y a través de un

túnel.

18 PDA. Ver glosario

93

En adición a los riesgos de seguridad, hay aspectos de calidad en el servicio concernientes

al Internet que se deben de tratar. La calidad en el servicio se refiere al acuerdo de servicio

ofrecido por un Proveedor de Servicios de Internet (ISP) a un cliente, que garantiza cierto

nivel de desempeño.

• Costos: ahorran grandes sumas de dinero en líneas dedicadas o enlaces físicos, reduce el

costo del servicio de comunicación o del ancho de banda de transporte, y también el

de la infraestructura y operación de las comunicaciones

• Flexibilidad: Se puede optar por múltiples tecnologías o proveedores de servicio. Esa

independencia posibilita que la red se adapte a los requerimientos de los negocios, y

se puede elegir el medio de acceso más adecuado.

• Mejor administración: cada usuario que se conecta puede tener un numero de IP fijo

asignado por el administrador, lo que facilita algunas tareas como por ejemplo

mandar impresiones remotamente, aunque también es posible asignar las direcciones

IP dinámicamente si así se requiere.

• Facilidad para los usuarios con poca experiencia para conectarse a grandes redes

corporativas transfiriendo sus datos de forma segura.

• Implementación rápida: La flexibilidad de esta arquitectura permite implementar nuevos

servicios de manera muy rápida, que concuerdan con los tiempos del negocio de las

empresas.

• Escalabilidad: El desarrollo masivo de redes como Internet permite que la empresa tenga

puntos de presencia en todo tipo de lugares. Por otro lado, la independencia con

respecto a la tecnología de acceso posibilita escalar el ancho de banda de la red

De acuerdo con el requerimiento del usuario. Además, la escalabilidad de la red no incide

en la operatoria y gestión de ésta, dado que la infraestructura de la WAN es responsabilidad

del proveedor del servicio.

94

4.3 Requerimientos básicos de las VPN.

Al implementar una solución de red remota, se desea facilitar un acceso controlado a los

recursos y a la información de la misma esta deberá permitir la libertad para que los clientes

roaming o remotos autorizados se conecten con facilidad a los recursos corporativos de la

red de área local (LAN) así como las oficinas remotas se conecten entre si para compartir

recursos e información (conexiones de N). Por último, la solución debe garantizar la

privacidad y la integridad de los datos al viajar a través de Internet público, lo mismo se

aplica en el caso de datos sensibles que viajan a través de una red corporativa, por lo tanto,

como mínimo, una solución de VPN debe proporcionar:

Autenticación de usuario: se deberá verificar la identidad de un usuario y restringir el

acceso de la VPN a usuarios no autorizados. Además proporcionar registros de auditoria

para mostrar quién accedió a qué información y cuándo.

Administración de dirección: La solución deberá asignar una dirección al cliente en la red

privada, y asegurarse de que las direcciones privadas se mantengan así.

Encriptación de datos: Los datos que viajan en una red pública no podrán ser leídos por

clientes no autorizados en la red.

Administración de llaves: se deberán generar y renovar las llaves de encriptación para el

cliente y para el servidor.

Soporte de protocolo múltiple: convendrá manejar protocolos comunes utilizados en las

redes públicas; éstos incluyen protocolo de Internet. Una solución de VPN de Internet

basada en un Protocolo de Túnel de Punto a Punto (PPTP) o un Protocolo de túnel de nivel

2 (L2TP) cumple con todos estos requerimientos básicos, y aprovecha la amplia

disponibilidad de Internet a nivel mundial.

95

4.4 Tipos de VPN. Las formas en que pueden implementar las VPN pueden ser basadas en hardware o a

través de software, pero lo más importante es el protocolo que se utilice para la

implementación.

Las VPN basadas en hardware utilizan básicamente equipos dedicados como por

ejemplo los routers, son seguros y fáciles de usar, ofreciendo gran rendimiento ya que

todos los procesos están dedicados al funcionamiento de la red a diferencia de un sistema

operativo el cual utiliza muchos recursos del procesador para brindar otros servicios, en

síntesis, los equipos dedicados son de fácil implementación y buen rendimiento, solo que

las desventajas que tienen son su alto costo y que poseen sistemas operativos propios y a

veces también protocolos que son propietarios.

Trabajar en un sistema de túnel es un método que utiliza una infraestructura de la red para

transferir datos de una red sobre otra; los datos que serán transferidos (o carga útil) pueden

ser las tramas (o paquetes) de otro protocolo.

En lugar de enviar una trama a medida que es producida por el nodo promotor, el protocolo

de túnel la encapsula en un encabezado adicional. Éste proporciona información de

entubamiento de manera que la carga útil encapsulada pueda viajar a través de la red

intermedia.

De esta manera, se pueden enrutar los paquetes encapsulados entre los puntos finales del

túnel sobre la red (la trayectoria lógica a través de la que viajan los paquetes encapsulados

en la red se denomina túnel). Cuando las tramas encapsuladas llegan a su destino sobre la

red se desencapsulan y se envían a su destino final; este sistema de túnel incluye todo este

proceso (encapsulamiento, transmisión y desencapsulamiento de paquetes).

Para que se establezca un túnel, tanto el cliente de éste como el servidor deberán utilizar el

mismo protocolo de túnel.

96

4.4.1 Diferentes tecnologías para armar VPN’s.

• DLSW: Data Link Switching (SNA over IP).

• IPX for Novell Netware over IP.

• GRE: Generic Routing Encapsulation.

• ATMP: Ascend Tunnel Management Protocol.

• IPSEC: Internet Protocol Security Tunnel Mode.

• PPTP: Point to Point Tunneling Protocol.

• L2TP: Layer To Tunneling Protocol.

Entre los más usados y con mejor rendimiento estarían IPSEC y PPTP, a continuación

se detalla su funcionamiento

4.4.1.1 IPSEC (Internet Protocol Secure).

Es un protocolo de seguridad creado para establecer comunicaciones que proporcionen

confidencialidad e integridad de los paquetes que se transmiten a través de Internet, puede

utilizar dos métodos para brindar seguridad, ESP (Encapsulating Security Payload) o AH

(Authentication Header), la diferencia entre ESP y AH es que el primero cifra los

paquetes con algoritmos de cifrado definidos y los autentica, en tanto que AH solo los

autentica, firma digitalmente los paquetes asegurándose la identidad del emisor y del

receptor.

IPSEC tiene dos tipos de funcionamiento, uno es el modo transporte en el cual la

encriptación se produce de extremo a extremo, por lo que todas las maquinas de la red

deben soportar IPSEC, y el otro es el modo túnel, en el cual la encriptación se produce solo

entre los routers de cada red.

4.4.1.2 PPTP (Point to Point Tunneling Protocol).

Protocolo PPTP (Point to Point Tunneling Protocol).

97

El PPTP es un protocolo de red que permite el tráfico seguro de datos desde un cliente

remoto a un servidor corporativo privado, estableciéndose así una Red Privada Virtual

(VPN) basada en TCP/IP. PPTP soporta múltiples protocolos de red (IP, IPX y NetBEUI) y

puede ser utilizado para establecer dichas redes virtuales a través de otras redes públicas o

privadas como líneas telefónicas, redes de área local o extensa (LAN's y WAN's) e Internet

u otras redes públicas basadas en TCP/IP.

El escenario más común para el funcionamiento de una vpn sobre protocolo pptp es el

siguiente: Una máquina cliente (Windows 9x, XP o Windows 2000) se conecta a un

Proveedor de Servicios de Internet (ISP) utilizando una conexión de acceso telefónico a

redes o bien usando una típica conexión ADSL o cablemodem.

En otro punto de Internet existe una máquina (por ejemplo, un servidor Linux) ofreciendo

servicio de conexión pptp. El cliente puede en ese momento lanzar una conexión de acceso

remoto usando su adaptador de red privada virtual a dicho servidor, creándose un túnel

privado sobre Internet que conecta ambas máquinas como si estuvieran en la misma red

local, pudiendo así tener acceso a recursos compartidos tales como carpetas o impresoras.

Este escenario puede variar según el tipo de conexión que tengan tanto el cliente como el

servidor. Organizaciones con acceso permanente a Internet, pueden configurar servidores

de acceso remoto para que soporten PPTP. Esto permite que colaboradores en cualquier

parte del mundo puedan conectarse a ellos, usando sus accesos a Internet habituales. Así,

será posible participar de los recursos de la red corporativa y con seguridad garantizada

gracias a los sistemas de encriptación de 128 bits.

4.5 Diagramas.

Hay varias posibilidades de conexiones VPN, esto será definido según los requerimientos

de la organización, por eso es aconsejable hacer un buen relevamiento a fin de obtener

datos como por ejemplo si lo que se desea enlazar son dos o más redes, o si solo se

conectaran usuarios remotos.

98

4.5.1 Diagrama de cliente a servidor.

Un usuario remoto que solo necesita servicios o aplicaciones que corren en el mismo

servidor VPN.

Figura 4.2 Diagrama de cliente / servidor.

4.5.2 De cliente a red interna LAN.

Un usuario remoto que utilizara servicios o aplicaciones que se encuentran en uno o más

equipos dentro de la red interna.

Figura 4.3 Diagrama de cliente a red interna.

4.5.3 De red interna a red interna (LAN a LAN).

Esta forma supone la posibilidad de unir dos intranets a través de dos enrutadores, el

servidor VPN en una de las intranets y el cliente VPN en la otra.

99

Aquí entran en juego el mantenimiento de tablas de ruteo y enmascaramiento.

Figura 4.4 De red interna a red interna (LAN a LAN).

4.6 Requerimientos para el armado de una VPN.

Para configurar una vpn bajo protocolo pptp necesitamos un servidor, un cliente (tantos

como deseemos) y una conexión a Internet para cada uno de ellos.

El servidor puede ser una distribución cualquiera de Linux configurada con el servicio

Poptop, que es el encargado de ofrecer conexiones PPTP. No necesita grandes requisitos de

hardware y con un procesador Pentium III con 128 megas de RAM como mínimo,

podremos ofrecer conexiones a la vpn a un máximo de 15 a 20 clientes aproximadamente.

El cliente puede ser una máquina con cualquier Windows, desde Windows 98 hasta

Windows 2003, pasando por XP o Windows 2000. En todo caso, se recomienda usar

Windows 2000 o XP ya que su soporte de compresión de tráfico y su mayor nivel de

encriptación ofrecerán un mejor rendimiento al conectarse a la vpn.

En cuanto a los protocolos de red necesarios, PPTP permite el uso de redes privadas

virtuales sobre redes TCP/IP ya existentes, como Internet, pero preservando el uso de los

protocolos de red, direcciones de nodo y nombres de máquinas ya existentes en la red

privada. Por tanto, no se requiere el uso de nuevos protocolos ni cambios en las

aplicaciones de red.

100

Mediante el "túnel privado" que se establece a través de la red pública TCP/IP, pueden

usarse, por ejemplo, los protocolos IPX y NetBEUI usados en la red privada para la

ejecución de las aplicaciones de red.

En cuanto a las garantías de seguridad que ofrece PPTP, la autentificación de usuarios se

realiza a través de los protocolos PAP y CHAP). PPTP hace uso de la seguridad que da el

protocolo PPP. La autentificación MS-CHAP se utiliza para validar las credenciales del

usuario remoto contra dominios NT a través del servidor Linux con PPTP, capaz de emular

cualquier tipo de conexión y protocolo desde y hacia sistemas Windows.

Sólo los usuarios con permiso para ello pueden realizar la conexión. Una vez que se

comprueba que el usuario tiene permiso (es decir, que su nombre de usuario y contraseñas

existen) para iniciar una sesión, se genera una "llave" de 40 bits en Windows 98 y NT y de

128 bits en XP y Windows 2000 a partir de la clave del usuario (llave que siempre viaja ya

encriptada por la red) que es utilizada para encriptar a su vez los datos del usuario.

4.7 Instalación y configuración de pptp en Linux.

En Linux tenemos soporte para vpns bajo protocolo pptp gracias al proyecto Poptop,

encargado de la creación del programa pptpd que es el que usaremos para crear nuestra vpn.

Básicamente y con el uso de este programa, conseguiremos que los clientes Windows

accedan a nuestra red local asignándoles un interfaz de red nuevo en el servidor pptp (un

interfaz que realmente es virtual, no va asociado a ningún hardware en especial) con una

dirección IP capaz de llegar a nuestra redes locales. El procolo pptp, al estar basado en

conexiones punto a punto con protocolo ppp, creará en nuestro servidor sencillos interfaces

ppp. A cada conexión pptp nueva tendremos un nuevo interfaz ppp, empezando desde el

ppp0 y subiendo a 1, 2, 3, etc a cada nueva conexión simultánea que obtengamos.

Para la instalación del soporte pptp para Linux tenemos dos opciones, o bien usar el soporte

pptp simple sin encriptación, con el cual nos ahorramos tener que modificar nuestro kernel

(el núcleo del sistema) para añadirle soporte de encriptación MPPE o bien optar por acabar

101

modificando nuestro kernel para añadirle dicho soporte, con lo que obtendremos un sistema

mucho mas seguro al estar protegido por una potente encriptación de hasta 128 bits.

En primera instancia utilizaremos la primera opción, por lo que necesitaremos el paquete

que nos proporciona el sistema de vpn por pptp que podremos obtener desde la web del

proyecto Poptop (www.poptop.org) o en otros casos obtener el paquete desde nuestra

propio distribución, que normalmente recibirá el nombre de pptpd (p.ej., en Debian o

RedHat, ya sea en formato .deb o en formato .rpm, dependiendo de nuestra distribución).

Su instalación es sencilla y de configuración muy fácil, ya sea instalando el paquete de

nuestra distribución o compilándolo nosotros mismos.

Tendremos tres archivos básicos que tendremos que controlar para poder poner en marcha

nuestra vpn con pptp. Estos tres archivos son: pptpd.conf, pptpd-options y ppp/chap-

secrets.

Por otro lado, tenemos el archivo /etc/init.d/pptpd con el cual, pasándole el parámetro stop

o start podremos arrancar o parar nuestra vpn.

4.7.1 Archivo pptpd.conf.

Este archivo tiene muy pocas opciones de configuración que necesitemos considerar. Las

opción speed no tiene ninguna utilidad si nuestro servidor va a funcionar sobre redes

ethernet. Pongamos lo que pongamos, siempre irá a la máxima velocidad que nuestra red

permita.

La opción debug nos permitirá ver en los logs todos y cada uno de los pasos y procesos que

realiza nuestro servidor pptp para establecer las conexiones de los clientes. Tenerla activada

puede ser una buena ayuda cuando nuestro servidor no funciona y no sabemos porque, ya

que obtendremos mucha más información de los logs del sistema y podremos buscar entre

ellos donde estamos fallando.

102

La opción option especifica el archivo de opciones de conexión (donde especificamos

encriptación, servidores dns, etc.), que por defecto es /etc/ppp/pptpd-options y que en

principio no necesitamos cambiar para nada.

Las opciones localip y remoteip si que tienen bastante mas importáncia ya con ellas

especificaremos los rangos ip de nuestra vpn. En localip bastará con especificar una de las

IPs locales que pueda tener nuestro servidor pptp (si solo tiene una, pues esa misma

servirá).

En remoteip tendremos que especificar el rango de direcciones IP que asignaremos a

aquellos clientes que se conecten a nuestra red via pptp. Podemos usar direcciones de un

rango de red ya creado (obviamente, deben ser direcciones IP que nadie esté utilizando) o

bien crear un rango de red propio que solamente utilizarán las máquinas que se conecten

usando la vpn y que se comunicará con el resto de nuestros rangos locales gracias al mismo

servidor pptp, que automáticamente enrutará las maquinas que entren vpn hacia todos los

rangos de red que el mismo servidor pptp sea capaz de encontrar en su misma red local.

Podemos especificar grupos de IPs, para no agotar todo el rango. P.ej, remoteip

192.168.5.1-100 solo asignará ips entre 192.168.5.1 hasta la 192.168.5.100.

4.7.2 Archivo /etc/ppp/pptpd-options.

Aquí las opciones que encontramos ya son bastante más extensas. Básicamente, en este

archivo definimos cosas como el tipo de autentificación (chap, require-chap, require-

chapms, etc.) o simplemente si queremos autentificación (auth), si queremos ampliar el

nivel de registro de la vpn en los logs al establecer el interfaz ppp (debug). Básicamente

todas estas opciones, aquellas que necesitemos para un funcionamiento básicos, ya vienen

activadas y los cambios que necesitaremos realizar en este archivo son mínimos.

Opciones a tener en cuenta son ms-dns y ms-wins, donde estableceremos, si los tenemos,

los servidores dns y wins de nuestra red local para que las máquinas que entran a través de

103

la vpn sean capaces de encontrar los nombres de los ordenadores de nuestra red local. La

opción domain nos permite especificar el dominio Windows de nuestra red local, siempre y

cuando lo tengamos.

Opciones como nodefaultroute o proxyarp nos permiten adoptar o no las rutas por defecto

del servidor al que nos conectamos o la realización o no de un proxy arp, esta opción es

necesaria si estamos creando nuestra vpn en un segmento de red distinto al de nuestra

propia red local.

En el caso de querer activar la encriptación, esta dependerá del cliente. Sin especificar

opción alguna en el servidor, este aceptará el nivel de encriptación o no dependiendo de lo

que quiera hacer el cliente, sin obligación alguna para que encripte sus datos o no. Si

queremos obligar a que el cliente encripte sus conexiones, podriamos añadir las opciones:

mppe required, obligamos a usar cualquier tipo de encriptación al cliente.

mppe no40, desactivamos el uso de llaves de 40 bits.



Si tan solo queremos que encripten datos a 128, activaremos las tres primeras opciones, con

lo que obligaremos a encriptar a 128. Hay que tener en cuenta, de todos modos, que si son

Windows 98 o inferiores los que se conectarán a nuestra vpn, en principio estos encriptan

tan solo con llaves de 40 bits.

4.7.3 Archivo /etc/ppp/chap-secrets.

En este archivo básicamente creamos los nombres y contraseñas de los usuarios de la vpn,

es decir, de aquellos usuarios que podrán acceder a nuestra red local a través de nuestro

servidor pptpd.

Básicamente, pondremos el nombre del usuario en la primera columna de la izquierda y su

contraseña en la tercera columna. Esta contraseña está en texto plano, por lo que los

permisos de este archivo chap-secrets deben ser continuamente vigilados para que

104

solamente root pueda ver su contenido. Finalmente, si deseamos que un usuario en concreto

siempre que se conecte a la vpn lo haga con la misma ip, podemos añadir la ip que

deseamos que use en la última de las columnas, teniendo en cuenta que esa ip ha de entrar

dentro del rango que ya definimos en el archivo pptpd.conf.

Esta es la configuración básica de nuestro servidor pptp y con esta ya podríamos ofrecer

acceso a él, para cualquier cliente que soportará dicho protocolo.

4.7.4 Depurando errores.

¿Que ocurre si algo funciona mal? ¿Donde podemos encontrar que y porqué está fallando

nuestro servicio pptpd? La solución es mirar los logs, los registros en los que el pptpd

guarda acción que realiza, ya sea esta satisfactoria o no. Para ello lo mas adecuado es

activar las opciones debug tanto en el pptpd.conf como en pptpd-options y disponernos a

observar todo lo que aparezca en los logs. Generalmente dichos logs los encontraremos en

/var/log/syslog (en Debian) o, mas comúnmente en otras distribuciones, en

/var/log/messages.

4.7.5 Configuración de los clientes pptp.

En principio cualquier sistema operativo con soporte de protocolo pptp será capaz de

conectarse a nuestro pptpd con Linux, pero, normalmente los que se conecten serán clientes

con Windows en cualquiera de sus distintas versiones.

La configuración de Windows para que se conecte a una vpn vía pptp es muy sencilla y no

requiere de instalar ninguna adicional.

Únicamente tenemos que crear una nueva conexión de acceso a redes y seleccionar una

conexión a redes privadas virtuales.

Pero realmente dependiendo de cada Windows la configuración cambiará en pequeños

detalles por lo que para cada modelo de Windows tendremos que tener en cuenta sus

especificaciones.

105

Conclusiones.

Como punto final del desarrollo del presente trabajo se puede concluir que las ventajas que

nos ofrecen las nuevas tecnologías permiten disponer de herramientas informáticas de alta

calidad, confiables, teniendo la oportunidad de accederlas desde cualquier lugar y en

cualquier momento.

Durante esta investigación se realizo una evaluación sobre sistemas web existentes de

aplicación de educación en línea (E-learning), los cuales engloban varias acciones y por

ende es más costosa y requiere mayor infraestructura tecnológica y humana para

implementarlas. Sin embargo no encontramos una aplicación en español que permita

únicamente la creación y administración de exámenes, con bajo costo y de manera sencilla.

Esto se considero debido a que nuestra aplicación esta diseñada para empresas y/o

instituciones que cuentan con una infraestructura pequeña y que su solvencia es limitada.

Se llevó a cabo un proceso de levantamiento de requerimientos, de manera que en el

transcurso del desarrollo se cumplió con los mismos.

El manejo adecuado de los protocolos que permitan establecer políticas y modelos de

seguridad. Así lograremos seguridad y confiabilidad durante la interacción entre el

sistema y el usuario final, garantizando la integridad y disponibilidad de la información.

Durante la investigación realizada concluimos que es importante que cualquier institución

educativa y de negocios pueda contar con una aplicación como la que nosotros proponemos

para la elaboración de evaluaciones remotas, creemos que será la manera en que se evaluará

el desempeño de las personas en un futuro inmediato.

106

Bibliografía.

Jacaboson, I., Booch, G., Rumbaugh J.

El Proceso Unificado de Desarrollo de Software, sexta edición

Editorial Addison Wesley 2006.

Sommerville, I.,

Ingeniería de Software

Editorial Pearson Educación, 2002.

Stephen r. Schach

Ingeniería de software clásica y orientada a objetos, sexta edición.

Editorial Mcgraw Hill 2002

www.sialatecnologia.org/documentos/borrador-tecnologia-informatica-31oct06.doc (3

abril 08).

http://www.camaguey.jovenclub.cu/munic/cruz/redes/pages/arquitectura.htm (3 abril 08).

www.lugro.org.ar/biblioteca/articulos/introvpn.pdf (3 abril 08).

http://www.agapea.com/El-lenguaje-unificado-de-modelado-UML-2-0-guia-de-usuario-

aprenda-UML-directamente-de-sus-creadores-n616247i.htm. (17 Abril 2008; 17:30 hrs).

http://www.ingenieria.cl/escuelas/informatica/apuntes_curso_uml/Diagramas%20de%20Ob

jeto.pdf. (21 Abril 2008; 16:50 hrs).

http://usuarios.lycos.es/oopere/uml.htm. (23 Abril 2008; 19:37 hrs).

http://merinde.rinde.gob.ve/index.php?option=com_content&task=category&sectionid=11&id=115&Itemid=296 (27 de Mayo 2008 14:09 hrs).

107

http://www.camaguey.jovenclub.cu/munic/cruz/redes/pages/arquitectura.htm

http://www.lugro.org.ar/biblioteca/articulos/introvpn.pdf

http://www.enterate.unam.mx/Articulos/2006/febrero/arquitec.htm (26 de Mayo 2008

12:09 hrs).

108

http://www.enterate.unam.mx/Articulos/2006/febrero/arquitec.htm

Glosario.

Artefacto: Es una pieza de información que es producida, modificada o usada por el

proceso, define un área de responsabilidad para un rol y está sujeta a

control de versiones. Un artefacto puede ser un modelo, un elemento de

modelo o un documento.

CASE: Computer-Aided Software Engineering.

Cardinalidades: Expresan cuántas del conjunto de entidades de un extremo de la relación

están relacionadas con cuántas entidades del conjunto del otro extremo.

Pueden ser ``uno a uno'', ``uno a varios'' o ``varios a varios''.

Codificar: Escribir instrucciones en un lenguaje de programación para que la

computadora las ejecute.

Crackers: Del inglés crack, romper. Es alguien que viola la seguridad de un sistema

informático con fines de beneficio personal o para hacer daño.

Criptográficas: Técnicas que hagan posible el intercambio de mensajes de manera segura

que sólo puedan ser leídos por las personas a quienes van dirigidos.

E-larning: Término utilizado para la educación no presencial a distancia.

Hackers: Es el neologismo utilizado para referirse a un experto en varias o alguna

rama técnica relacionada con la informática: programación, redes de

computadoras, sistemas operativos, hardware de red/voz, etc.

Iteraciones: Se refiere a la técnica de desarrollar y entregar componente incrementales

de funcionalidades de un negocio.

109

http://es.wikipedia.org/wiki/Sistema_inform%C3%A1tico

http://es.wikipedia.org/wiki/Sistema_inform%C3%A1tico

http://es.wikipedia.org/wiki/Inform%C3%A1tica

http://es.wikipedia.org/wiki/Programaci%C3%B3n

http://es.wikipedia.org/wiki/Redes_de_computadoras

http://es.wikipedia.org/wiki/Redes_de_computadoras

http://es.wikipedia.org/wiki/Sistema_operativo

Modelado: Es una técnica cognitiva que consiste en crear una representación ideal de

un objeto real mediante un conjunto de simplificaciones y abstracciones,

cuya validez se pretende constatar.

PDA: Del inglés Personal Digital Assistant (Asistente Digital Personal)

computador de mano originalmente diseñado como agenda electrónica

(calendario, lista de contactos, bloc de notas y recordatorios) con un

sistema de reconocimiento de escritura.

SGDB: Sistemas de gestión de base de datos, un tipo de software específico,

dedicado a servir de interfaz entre la base de datos, el usuario y las

aplicaciones que la utilizan.

Trazabilidad: Conjunto de procedimientos establecidos que permite conocer el histórico,

ubicación y trayectoria de un producto a lo largo de toda la cadena de

suministro.

110

escuela superior de ingenierÍa mecÁnica y electrica …

Documents