Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Snnifer (001-040) (1) .Ca - Es
Snnifer (001-040) (1) .Ca - Es
com
SNIFFER
PROYECTO FINAL DE CARRERA
FACULTAD DE TELECOMUNICACIONES
DE BARCELONA
SNIFFER
Título: SNIFFER
Volumen: 1/1
Alumno: Joaquim Orra Serra
1
SNIFFER
Título: SNIFFER
Volumen: 1/1
Alumno: Joaquim Orra Serra
CALIFICACIÓN
Calificación numérica:
Calificación descriptiva:
Fecha:
2
SNIFFER
ÍNDICE
3
SNIFFER
4
SNIFFER
ÍNDICE DE FIGURAS
5
SNIFFER
1 Introducción
Durante los siete meses que he estado realizando el Proyecto Final de Carrera, muchas
personas me han preguntado qué proyecto estaba desarrollando. Yo respondía, un
Sniffer. Esta respuesta no satisfacía, por tanto, pensé en otra respuesta. Ésta fue, un
capturador de tráfico de internet. Al ver que esta respuesta tampoco acababa de
satisfacer, y que es un concepto difícil de entender por quienes son ajenos a este mundo,
pensé en algo metafórico conocido por todos.
La respuesta fue contar lo que hace la policía cuando pincha una línea telefónica.
Esa respuesta fue la definitiva.
1.1 La memoria
En el capítulo dos se explican los distintos tipos de sniffers que existen y, las
diferentes tecnologías de distribución y web que existen. En el capítulo tres se ha
estudiado los diferentes requisitos que debería cumplir la aplicación. El capítulo cuatro
habla de la metodología que he seguido junto con una planificación económica y
tormenta. El quinto y sexto capítulos serían los más densos que se explica el diseño
del Proyecto y su implementación.
Una vez terminada la aplicación es necesario realizar una serie de pruebas para verificar que se
cumplen los requisitos establecidos en el capítulo tres. Estas pruebas y su descripción se
encuentran en el capítulo siete.
El último capítulo son las conclusiones que se han extraído de la realización del proyecto y
posibles nuevas funcionalidades para incorporar en un futuro.
1.2 El proyecto
La primera fue documentarme sobre qué es y cómo trabajan los sniffers, instalar,
hacer funcionar, entender la aplicación de escritorio sobre la que desarrollé mi
proyecto. Esta parte fue complicada debido a mi inexperiencia con curva, con sniffers
y con aplicaciones de escritorio.
6
SNIFFER
La segunda fue el desarrollo de una aplicación web que se comunicaba con el servidor de
capturas de la aplicación original. Esta segunda fue bastante complicada ya que la
aplicación tenía que comunicarse con tres elementos imprescindibles; el servidor de
capturas ya comentado y dos servidores de aplicaciones con sus correspondientes
máquinas virtuales.
Estas dos partes han sido asentadas cronológicamente una después de la otra ya que
primero era necesario investigar y profundizar en lo que había hecho y después crear
una versión mejor.
Gracias al proyecto hemos pasado de un sniffer que era una aplicación de escritorio a tener
una aplicación web que integra un sniffer. Veremos cuáles son los cambios que se han
realizado en la aplicación original para adaptarla y también cómo se ha diseñado el entorno
web para albergar un servidor de capturas desarrollado con Curva y C++.
Éste es un proyecto muy interesante para quienes quieran adentrarse en el mundo de los
sniffers.
La historia del proyecto empezó caro el día que fui a hablar con Isaac Gelado. Yo
quería un proyecto de J2EE puesto que es el lenguaje de programación que utilizo en
el trabajo. Ese día me propuso hacer un proyecto y me dijo que crees si lo quería
llevar a cabo.
Dejé pasar el verano y en septiembre del 2008 volví a su despacho. Me dijo que el
proyecto que me había comentado estaba asignado. Sin embargo, hemos propuesto
otro muy interesante. El proyecto trataba de tomar una aplicación de escritorio y
convertirla en una aplicación web. Además, la aplicación era un Sniffer. La idea me
gustó tanto que me eché de cabeza.
1.4 Utilidad
Sniffer bien del inglés “sniff” que significa olisquear. Es esencialmente un programa que
captura las tramas de la red y que generalmente se utiliza para gestionar redes.
Es común, debido a la topología de red, tener un medio de transmisión compartido por varias
máquinas y dispositivos. Por tanto un ordenador, puede capturar tramas que no están
destinadas a él y de esta manera gestionar una red.
Permite ver y analizar la información real que viaja por la red. Por este motivo, los sniffers
han sido utilizados por muchos hackers para capturar contraseñas y nombres.
7
SNIFFER
Permite analizar errores en la red y ver por ejemplo por qué un ordenador A no puede
establecer comunicación con un ordenador B.
Así pues, vemos que un sniffer es una herramienta muy potente y eficaz si se quiere entender
cómo funciona una red.
Los sniffers tienen otras utilidades como pueden ser detectar problemas de conectividad
en una red o depurar aplicaciones de red. Permite estudiar las redes descubriendo
puntos críticos como los cuellos de botella y las vulnerabilidades de la red.
Los sniffers también son útiles para detectar intrusos en la red o para investigar a los
posibles hackers de una red. Muchos sniffers dedicados a investigar hackers permiten la
creación de registros de red de modo que los hackers puedan saber que son
investigados.
1.5 Objetivos
El primer objetivo es que la aplicación muestre capturas por pantalla. Dentro de este
apartado podríamos definir objetivos menos importantes pero no menos necesarios.
Guardar las capturas, ver los diferentes sniffers que se encuentran en la red, poder filtrar
capturas por ip, puerto y protocolo, reconfigurar el filtro de capturas son objetivos que se
tendrán que ir alcanzando una vez se haya llevado a cabo el primero objetivo
mencionado anteriormente.
Uno de los objetivos más importantes es que la aplicación sea eficiente y rápida. Que el código de
que la forma sea robusto y las tecnologías utilizadas también. Habrá, por tanto, que razonar muy
bien a la hora de tomar decisiones de diseño de la aplicación.
La aplicación deberá ser vistosa y entendedora por tanto los estilos y las decisiones
estructurales también tendrán que ser meditadas con detenimiento.
8
SNIFFER
La mayoría de sniffers que corren en sistemas Unix tienen como librería base
"libpcap".
Libpcap es una librería “open source”, la cual ofrece un apio para poder realizar capturas
de tráfico. Incluye un analizador sintáctico para cadenas de filtrado lo que la hace
relativamente fácil de utilizar. Se encuentra disponible para C y C++. Existen sin embargo
“wrappers” que son finas capas que transforman las interfaces de las librerías para que
sean entendibles por otros lenguajes. Por pcap existen wrappers para Java y .NET.
Hay que decir que para windows también existe una versión “winpcap”. Estas librerías
contienen métodos de bajo nivel, que permiten realizar capturas de tráfico a aplicaciones
web o de escritorio. Sin embargo no hay que pensar que libpcap y winpcap son la misma
librería, mientras libpcap accede a un módulo dentro del kernel, winpcap no lo hace ya que
los sistemas windows no implementan este módulo. El filtrado lo realizan dentro de la misma
librería con lo que la hace menos eficiente.
Para utilizar esta librería dentro de cualquier aplicación primero hay que buscar un
dispositivo para empezar la captura, extraer la dirección de red y su mascara, definir el
filtro de las capturas, compilarlo y relacionarlo con la captura y finalmente empezar la
captura. La captura será en modo promiscuo, es decir, que capturará todos los paquetes
de red aunque no pasen por la máquina donde se encuentra instalado el sniffer. Por
tanto, en este caso, será necesario que el usuario ejecute el sniffer como
Administrador(superusuario).
Cabe señalar que libpcap también cuenta con métodos que detectan posibles errores que podrían hacer
inviables las capturas.
9
SNIFFER
Las capturas de tráfico se empezaron a utilizar sobre todo en sistemas UNIX ya que se
comprobó que eran muy eficaces para monitorizar y detectar errores y puntos débiles
en las redes. Para que esta técnica sea eficaz debe realizarse en cualquier
punto de la red, especialmente en zonas donde la red pueda ser vulnerable.
En 1980 salió "ICMU/Standford Packet Filter (CSPF)" que ofrecía grandes ventajas. Sin
embargo con la progresiva migración hacia sistemas RISC, este filtro diseñado para
máquinas basadas en pilas de memoria, decayó enormemente. Estas nuevas
arquitecturas hacían un uso exhaustivo de los recursos.
En 1992 aparece BSD “Packet Filter” que constituye una nueva y mejor
implementación de captura de paquetes en el kernel. Este sistema está diseñado
especialmente para máquinas basadas en registros. Además presenta un nuevo
esquema de filtrado que le hace mucho mejor que sus antecesores. De hecho, hoy en
día, una versión de éste es la más utilizada y está presente en el kernel de muchos
sistemas operativos.
En este capítulo explicaré brevemente los distintos sniffers que existen. Todos ellos
permiten examinar datos de una red viva y solucionar problemas en redes de
comunicación.
Wireshark
10
SNIFFER
una interfaz gráfica con la posibilidad de generar gráficas de las capturas, muchas
opciones de organización y un filtrado de información. Es capaz de detectar problemas
en la red.
11
SNIFFER
Ettercap
Es un sniffer por redes conmutadas “Open Source”. Soporta direcciones activas y pasivas de
diferentes protocolos (incluso cifrados como SSH y HTTPS). Hace posible la inyección de datos
en una conexión establecida. Es capaz de filtrar manteniendo la conexión gracias a que
puede establecer un Ataque Man-in-the-middle(Spoofing) o envenenamiento de tablas ARP
(arp Spoofing). Este sniffer tiene como librerías base libpcap, libnet, libpthread y Zlib.
También es capaz de detectar un sistema operativo remoto. Ettercap genera un archivo log
donde guarda, en formato binario, las capturas realizadas.
TCPDump
Es un sniffer por redes TCP/IP. Monitoriza los paquetes que entran y salen de la
interfaz de red y los presenta en formato legible. Permite utilizar filtros mediante una
expresión de búsqueda, de modo que sólo muestra los paquetes cuya cabecera
coincide con ella. También puede utilizarse para la ingeniería inversa de protocolos de
red. Para capturar todo el tráfico dirigido a la interfaz, debe colocarse en modo
promiscuo. Puede capturar paquetes en redes con enrutamientos no inteligentes
como podría ser un swicth o un router. En redes WI-FI puede capturar todos los
paquetes que lleguen a la antena y sean reconocidos, de cualquier red disponible e
incluso varios canales simultáneos, siempre que sean adyacentes y que la tarjeta no
sea muy selectiva en frecuencia. Utiliza la librería pcap.
Win Sniffer
Como todos los sniffers sirve para administrar redes, pero a diferencia de otros permite
reconstruir el tráfico de la red de forma simple y comprensible mientras otros sniffers
sólo muestran los paquetes capturados. Puede capturar paquetes en modo promiscuo.
Además, puede descodificar FTP, POP3, HTTP, ICQ, SMTP, Telnet, IMAP y contraseñas
NNTP. Tiene un filtro por paquetes muy intuitivo. Tiene la posibilidad de ser
12
SNIFFER
dejado días enteros capturando tráfico ya que las capturas las guarda en logs.
Darkstat
La diferencia de este sniffer en comparación con otros es que una vez hechas las
capturas genera un informe en formato HTML y permite realizar estadísticas de
direcciones que se generan durante la comunicación entre hosts, del tráfico que se
produce y de los diferentes puertos utilizados por los diversos protocolos.
Taffic-Vis
Este sniffer monitoriza tráfico TCP/IP y con esta información genera gráficos con ASCII,
HTML o Postscript. También permite analizar tráfico entre hosts para determinar qué
hosts se están comunicando y el volumen de la comunicación. Utiliza como muchos otros
sniffers la librería libpcap.
Kismet
Este sniffer funciona con cualquier tarjeta de cámara que admita monitoreo sin procesar
y puede capturar tráfico 802.11b, 802.11ay 802.11g. Se diferencia de otros sniffers
inalámbricos por su funcionamiento pasivo. Es decir, que captura tráfico sin enviar
ningún paquete detectable, permiten detectar la presencia de diferentes puntos de
acceso y clientes asociados unos con otros.
Hunt
Es otro ejemplo de sniffer que funciona con redes ethernet. Hunt examina la red
por ciertas firmas y diferentes patrones en cuyo tráfico indican un evento concreto
o una condición. Cuando reconoce una firma hunt entra en la sesión y da acceso a
una conexión establecida que puede ser utilizada para explorar la red.
13
SNIFFER
LinSniffer
Es un sniffer muy simple cuyo objetivo principal es capturar nombres de usuario y passwords. De
hecho, la información que muestra es perfecta para ver passwords y nombres de usuario pero no
está preparado para un análisis más detallado.
IPTraf
Es un monitor de red que genera gran variedad de estadísticas como información TCP,
contador UDP, información ICMP y OSPF, estado de los nodos, errores IP, etc.
También contiene filtros para diferentes protocolos para ver tan sólo la información que
nos interesa.
14
SNIFFER
Snort
Es un sniffer/logger que sirve para detectar intrusiones y ataques del tipo búfer
overflows, CGI, SMB, escaneo de puertos, etc. Es capaz de enviar alertas en tiempo
real, enviándolas directamente al archivo de Unix syslog o incluso a un sistema
Windows mediante SAMBA. Tiene muchos filtros y ciertos patrones. También dispone
de actualizaciones constantes para hacer frente a ataques, barridos o
vulnerabilidades que se vayan detectando. Podemos ver por consola los paquetes
que se van registrando y guardarlos en logs.
Otros sniffers:
15
SNIFFER
En la Figura 3 se puede ver una tabla con las principales características de los sniffers:
16
SNIFFER
17
SNIFFER
18
SNIFFER
Licencia: LL
Tipo de redes de las que puede capturar tráfico: TXCT
Protocolos que admite: PA
Librería base: LLB
Inyección datos en la conexión: IDC
Plataforma de ejecución: PE
Filtrar capturas: FC
Detección ataques: DA
Detección sistema operativo: DSO
Interfaz gráfica: IG
Guardar capturas: GC
Generación de documentos: GD
Generación de gráficos: GG Modo
Promiscu/No promiscu: MP
19
SNIFFER
2.5.1 Introducción
El tamaño del sistema puede ser muy variado, desde decenas de hosts(red de área local) y
cientos de hosts(red de área metropolitana), hasta millones de hosts (Internet).
Algunas de las características más importantes a las que desea llegar un sistema
distribuido son:
20
SNIFFER
2.5.2 Historia
De todas formas no fue hasta la aparición de TCP/IP, diseñado por Bob Kahn y Viton
Cerf, y con él la interconexión de redes en 1974 que las redes distribuidas tomaron un
cariz más importante el concepto de redes distribuidas.
En 1983, se define el protocolo TCP/IP como protocolo oficial y surgen las primeras redes
aplicaciones distribuidas.
Las tecnologías actuales se basan en el middleware. Éste lo podríamos definir como una
capa software entre los procesos de usuario y los del sistema operativo. Por tanto para el
programador queda escondida la complejidad del sistema operativo. Dentro de esta
tecnología encontramos middleware orientado a objetos que ha desarrollado Sun
Microsistems y la middleware orientado a componentes desarrollada por CORBA:OMG.
2.5.3 RPC
RPC proviene del inglés “Remote Procedure Call”. Es un protocolo que permite que un
programa ejecute código en una máquina remota sin preocuparse por la comunicación entre
ellas. RPC fue un gran antes, ya que al usar sockets, el programador tenía que estar atento a
las comunicaciones. Los RPC se utilizan ampliamente en entornos cliente-servidor. Siendo el
cliente quien inicia una petición para que se ejecute cierto código en el servidor.
Existen distintos tipos de RPCs, muchos de ellos estandarizados como puede ser el RPC
de Sun, ONC RPC, el RPC de OSF llamado DCE/RPC y el modelo de Objetos de
Componentes de Microsoft DCOM. Sin embargo ninguno de estos modelos es compatible
entre sí. La mayoría de ellos utilizan un lenguaje de descripción de interfaz IDL que
21
SNIFFER
Hoy en día es muy utilizado el XML como lenguaje para definir IDLs y HTTP como
protocolo de red.
RPC de Sun
Uno de RPC podría ser el RPC de Sun. Éste proporciona un lenguaje de definición de
interfaz llamado XDR(eXternal Data Representation) y un compilador de interfaces
llamado rpcgen. A partir de la interfaz definida con XDR y del compilador rpcgen se
obtienen la mayoría de los componentes de una RPC. Es decir:
El lenguaje XDR puede utilizarse no sólo para especificar las operaciones que ofrece el
servidor, sino también su identificador o número de servicio y su versión.
22
SNIFFER
Este lenguaje ofrece una notación similar a C. Este RPC puede pasar cualquier
estructura de datos como argumentos o resultados y dispone de unas rutinas
estándar de serialización de datos.
El RPC Sun no ofrece un servicio de binding a nivel de red, sino local. Es decir, que en
cada máquina hay un binder. Debido a esto este RPC no ofrece transparencia total, de
modo que el usuario debe realizar pequeñas modificaciones en las llamadas de su
programa.
2.5.4 RMI
RMI significa Java Remote Method Invocation y es un mecanismo que ofrece Java para
invocar un método de forma remota. Es un simple mecanismo para la comunicación
de servidores en aplicaciones distribuidas basadas exclusivamente en Java. Para la
comunicación entre otras tecnologías podemos utilizar CORBA o SOAP.
RMI se caracteriza por su facilidad de uso. La gran ventaja es que permite referencia a
objetos (no permitido por SOAP), recolección de basura distribuida (Garbage Collector
distribuido) y paso de tipos arbitrarios (funcionalidad que no ofrece CORBA).
Mediante RMI, un programa Java puede exportar un objeto. Esto significa que es
accesible a través de la red, mientras el servidor espera solicitudes a un puerto
TCP. Un cliente, por tanto, puede coger el objeto de la red e invocar sus métodos.
Un esquema de las partes de un sistema RMI lo podemos ver en la Figura 5.
Un objeto es remoto si sus métodos pueden invocarse por procesos que se encuentran en
otras máquinas virtuales.
En Java también encontramos dos tipos de interfaces. La local, accesible por procesos
dentro de la misma máquina virtual, y cuya remota recoge la declaración de las
operaciones que forman el servicio. A diferencia de CORBA los objetos que se pasan
23
SNIFFER
2.5.5 CURVA
24
SNIFFER
Para la transmisión tanto de la petición como de la respuesta interviene la interfaz del ORB.
Éste tiene dos tipos de interfaz: la pública que figura dentro del modelo de la OMG y la
privada que es la que generando los diferentes fabricantes para permitir la conexión entre
los stubs y la ORB.
25
SNIFFER
Curve ofrece un conjunto de objetos llamados instalaciones comunes. Éstos son servicios
útiles para cualquier entorno.
26
SNIFFER
2.5.6 J2EE
J2EE incluye varias especificaciones de API como podrían ser JDBC, RMI, e-mail, JMS,
Servicios Web o XML. J2EE también configura algunas especificaciones únicas. Algunos
ejemplos podrían ser Enterprise JavaBeans, servlets, portlets, JSP y diversas tecnologías
de servicios web.
Otras ventajas de utilizar J2EE son, por ejemplo, que el servidor de aplicaciones puede
manejar transacciones, la seguridad, la escalabilidad, concurrencia y gestión de los
componentes desplegados, lo que significa que los programadores pueden concentrarse más
con la lógica de negocio en lugar de preocuparse por temas de bajo nivel.
Hay que comentar también que una de las grandes ventajas de J2EE es que se puede empezar a
desarrollar una aplicación sin coste alguno.
Los estándares utilizados son: Web Services Stack, XML, SOAP o XML-RPC, WSDL,
UDDI, WS-Security y OASIS.
En cuanto a las ventajas de utilizar Servicios Web, las más importantes son:
27
SNIFFER
Sin embargo la principal razón para utilizar Servicios web es que se basan con HTTP
sobre TCP en el puerto 80. Como las organizaciones protegen sus redes por medio de
firewalls, cierran casi todos los puertos menos el puerto 80, que es, precisamente, lo que
utilizan los navegadores.
Otra razón por la que se utilizan los servicios web es porque antes de que existiera SOAP, no
había buenas interfaces para acceder a la funcionalidad de otras computadoras en la red.
Otra buena razón es su flexibilidad. Aportan independencia entre la aplicación que utiliza el
servicio Web y el propio servicio. Así los cambios en uno no deben afectar al otro. Esto es
bueno, ya que cada vez más se tiende a construir grandes aplicaciones a partir de
componentes más pequeños.
2.6.1 Struts
Struts es una herramienta de soporte para desarrollar aplicaciones web bajo el patrón MVC
(Modelo Vista Controlador) y bajo la plataforma J2EE. Struts permite reducir el tiempo de
desarrollo de una aplicación.
Una aplicación web no son sólo paginas html. Sino que puede producir respuestas
dinámicas. Una aplicación web puede tener interacción con bases de datos y lógica de
28
SNIFFER
negocio. Por ese motivo se creó el Modelo Vista Controlador. Así pues se complica
bastante el trabajo del programador y por este motivo aparece struts.
2.6.2 JSP
JSP es una tecnología que proporciona una forma rápida de crear páginas web con
contenido dinámico. En el fondo una JSP es un archivo de texto que tiene contenido
estático expresado con formato HTML, SVG, XML o WML y elementos JSP con contenido
dinámico.
Una JSP es traducida a un servlet antes de ser ejecutada, procesa una request HTTP y
genera una response al igual que cualquier servlet.
Las JSP conteniendo XML tags, muy útiles para ahorrar tiempo en la programación, y código javascript
para hacer más fácil ciertas partes del código. Sin embargo el javascript cambia según el navegador y
se convierte en una potencial fuente de error en aplicaciones web.
Una JSP toma los tags XML y los transforma en código estático HTML y después es compilada
para transformarla en un servlet, por tanto, es lógico pensar que necesita la Máquina Virtual
de Java para funcionar. También debe decirse que la JSP compilada se guarda en la memoria
del servidor y cuando vuelve a ser llamada el tiempo de ejecución mejora notablemente.
2.6.3 AJAX
29
SNIFFER
las aplicaciones.
Ajax es una tecnología asíncrona, en el sentido de que los datos adicionales se piden al
servidor y se cargan en segundo plano sin interferir con la visualización ni el
comportamiento de la JSP. JavaScript es el lenguaje que normalmente se utiliza para
realizar las funciones que realizan los llamamientos de AJAX, mientras que el acceso a los
datos se realiza mediante XMLHttpRequest. Sin embargo, no es necesario que el
contenido esté en formato XML.
Ajax es una técnica válida para muchas plataformas y utilizable por muchos sistemas
operativos y navegadores ya que está basado en estándares abiertos como Javascript y
Document Object Model.
30
SNIFFER
Antes de empezar a nombrar requisitos funcionales haré una breve definición. Un requisito
funcional define el comportamiento interno del software: cálculos, detalles técnicos,
manipulación de datos y otras funcionalidades específicas que muestran cómo los casos de
uso serán llevados a la práctica.
Hay 4 requisitos que son: guardar capturas, configurar nuevas capturas, abrir capturas y
borrar capturas. Éstos tendrían todos el mismo grado de importancia.
Guardar Capturas:Deberá existir un botón en la barra del menú superior para realizar esta
acción. Para cumplir este requisito será necesario que la aplicación guarde las capturas que
se encuentran con formato XML. Habrá que utilizar la librería JDOM para tratar las capturas y
transformarlas en un archivo XML, jerárquico.
Configurar nuevas capturas:Deberá existir un botón en la barra del menú superior para
realizar esta acción. Es importante poder volver a configurar una captura en cualquier
momento y no sólo cuando entramos en la aplicación. Habrá que modificar los
parámetros de la request para que el servidor utilice los nuevos valores.
Abrir capturas:Deberá existir un botón en la barra del menú superior para realizar esta
acción. Este requisito es necesario para complementar el requisito de guardar las
capturas. También será necesario utilizar JDOM para tratar las capturas y ponerlas en la
request para que la JSP la pueda entender.
Borrar capturas:Deberá existir un botón en la barra del menú superior para realizar esta
acción. Este requisito es indispensable ya que es necesario limpiar la mesa de capturas
después de varias capturas. Tan sólo es necesario limpiar la request de capturas y así la
librería displaytag no mostrará capturas.
31
SNIFFER
32
SNIFFER
La aplicación también tendrá que serefectiva.Para cumplir este requisito será necesario realizar
un buen control de errores y prever posibles errores que se puedan dar en tiempo de ejecución.
También será necesario desarrollar un código limpio, sin ciclos y sin redundancias.
La aplicación deberá estar en un entorno web para cumplir el requisito deno presencia física
. El usuario no tendrá que estar delante de la máquina para realizar capturas. Simplemente es
necesario tener internet para conectarse a la aplicación.
33
SNIFFER
34
SNIFFER
4 Metodología y planificación
La fase de análisis define los requerimientos del sistema. Sin tener en cuenta
cómo serán estos requerimientos llevados a cabo. Básicamente, en esta fase, se
define el problema que se está intentando resolver. El resultado final de esa etapa
es un documento de requerimientos.
La última fase, no por ello menos importante, es la fase de Test. En esta fase
confirmamos la calidad del producto entregado. Hay que tener en cuenta que es mejor
un producto con pocas funcionalidades pero bien probado que uno con muchas
funcionalidades pero fallos que lleven al no cumplimiento de los requisitos establecidos
en la primera fase.
35
SNIFFER
Una metodología secuencial suele utilizarse cuando la complejidad del proyecto es baja y los
requerimientos son estáticos. Muchas veces se empieza a picar código sin un buen analisis del
proyecto y después es necesario reescribirlo. Este contratiempo lo podemos evitar utilizando una
metodología secuencial.
Sin embargo hay alguna desventaja cuando utilizamos una metodología secuencial. Hay
que conocer perfectamente las tecnologías aplicables a la aplicación ya una vez realizado
el análisis ya no hay vuelta atrás. De ahí que un posible error en la etapa de
implementación no dejaría rehacer el análisis. Un esquema de esta metodología lo
podemos ver en la Figura 10.
36
SNIFFER
test.
En cada fase se dedica una pequeña porción de tiempo y se va iterando por cada una de
ellas. Así, todas las partes van cambiando a medida que el proyecto va avanzando. Esto
permite que fallos en los requerimientos o fallos frente a las tecnologías a utilizar se
puedan corregir. Cada una de las fases se intercomunica e interactúa con las demás para
mejorar todos los aspectos posibles de la aplicación.
Por otra parte, sin embargo, no hay un límite de iteraciones a realizar sobre las 4 fases y
es posible que cada vez una fase comporte más trabajo a otra. Posiblemente nunca se
llega a una estructura válida del proyecto.
En esta metodología es muy importante el aprendizaje durante el desarrollo, puesto que así
se puede aplicar a la siguiente iteración.
Esta metodología es iterativa. No intenta minimizar los cambios, sino que está
37
SNIFFER
● Definición de los requerimientos del sistema: El objetivo de esta fase es registrar todos
los requerimientos del usuario. Esta fase es la más importante puesto que se
determinan requisitos mediante la construcción, demostración y retroalimentación del
prototipo.
● Diseño técnico: Esta etapa contiene dos partes muy importantes, por un lado hay que
realizar la documentación del diseño que explica cómo será la estructura del software.
La segunda parte es la producción de todos los requerimientos y asegurar un fácil
mantenimiento del software en el futuro.
● Evaluación: Esta fase contiene dos partes muy importantes. Por un lado, extraer
del usuario los requerimientos adicionales del sistema y verificar que el prototipo
sea correcto con los requerimientos. Si se encuentran errores, el prototipo es
38