Post on 27-Jun-2022
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
Requisitos nuevoso modificados
Sistema nuevoo modificado
Proceso de Desarrollo de Software
Requisitos nuevoso modificados
Sistema nuevoo modificado
Proceso de Desarrollo de Software
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
Bosquejo de la Descripción
Especificación
Desarrollo
Validación
Versión Inicial
Versiones Intermedias
Versión Final
Bosquejo de la Descripción
Especificación
Desarrollo
Validación
Versión Inicial
Versiones Intermedias
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.
Definición de Requisitos
Análisis de Componentes
Modificación de Requisitos
Diseño del sistema con Reutilización
Desarrollo e Integración
Validación del Sistema
Definición de Requisitos
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
Diseño de la Base de Datos
Plan de transición
Diseño de la
Aplicación
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
Diseño de la Base de Datos
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.
Arquitectura del Sistema
Herramientas
Programasprobados
Especificación de los programas
Construcción
Diseño de la Base de Datos Base de datos
afinada
Arquitectura del Sistema
Herramientas
Diseño de la Base de Datos Base de datos
afinada
Programasprobados
Especificación de los programas
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 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 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
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
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.
Arquitectura de Software
Identificar los elementos de Diseño
Analizar los Casos de Uso
Modelo de AnálisisModelo de Diseño
Modelo de Diseño (Realizaciones de los
Casos de Uso)
Arquitectura de Software
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
Arquitectura de Software
Analizar la Interfaz de Usuario
Registro de Evaluación
Arquitectura de Software
Identificar los elementos de Diseño
Analizar los Casos de Uso
Modelo de AnálisisModelo de Diseño
Modelo de Diseño (Realizaciones de los
Casos de Uso)
Arquitectura de Software
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
Arquitectura de Software
Analizar la Interfaz de Usuario
Registro de Evaluació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
Especificación de Requerimientos del
Software (Especificaciones Suplementarias)
Arquitectura de Software
Analizar la Interfaz de Usuario
Modelo de Servicios
Modelo de Diseño
DISEÑAR LOS SERVICIOS
Modelo de Servicios
Documento de la Arquitectura del Software
Modelo de Diseño
Especificación de Requerimientos del
Software (Especificaciones Suplementarias)
Arquitectura de Software
Analizar la Interfaz de Usuario
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
Modelo de DiseñoModelo de Diseño
(Capsula)
Modelo de Análisis
Especificación deRequerimientos de
Software (Modelo de Caso de Uso))
Modelo de Diseño
Especificación de Requerimientos del
Software Mapa de Navegación
DISEÑAR LOS COMPONENTES
Modelo de Diseño
Registro de Evaluación
Diseñar Casos de Uso
Arquitectura de Software Revisar el Diseño
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
Modelo de DiseñoModelo de Diseño
(Capsula)
Modelo de Análisis
Especificación deRequerimientos de
Software (Modelo de Caso de Uso))
Modelo de Diseño
Especificación de Requerimientos del
Software Mapa de Navegación
DISEÑAR LOS COMPONENTES
Modelo de Diseño
Registro de Evaluación
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
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
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
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.
mppe no56, desactivamos el uso de llaves de 56 bits.
mppe no128, desactivamos el uso de llaves de 128 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§ionid=11&id=115&Itemid=296 (27 de Mayo 2008 14:09 hrs).
107
http://www.enterate.unam.mx/Articulos/2006/febrero/arquitec.htm (26 de Mayo 2008
12:09 hrs).
108
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
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