Prueba rapida para la deteccion de casos de

daltonismo en las escuelas de nivel basico.

Indice general
1. Planteamiento del problema
1.1. Objetivo . . . . . . . . . . .
1.2. Motivaci
on . . . . . . . . .
1.3. Justificaci
on . . . . . . . . .
1.4. Impacto econ
omico . . . . .
1.5. Impacto social . . . . . . .

.
.
.
.
.

.
.
.
.
.

2. Marco te
orico

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

5
6
6
6
6
7
9

3. Metodologa
13
3.1. Introducci
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Metodologa para el desarrollo de una prueba rapida para la detecci
on de casos de daltonismo en el nivel de educacion basica. . 14
3.2.1. An
alisis de requisitos: . . . . . . . . . . . . . . . . . . . . 14
3.2.2. Especificaci
on . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.3. Dise
no del programa . . . . . . . . . . . . . . . . . . . . . 17
3.2.4. Codificaci
on . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.5. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.6. Documentaci
on . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.7. Mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . 25

INDICE GENERAL

Captulo 1

Planteamiento del problema

La percepci
on del color es crucial para el desempe
no escolar; el color forma
parte de las actividades desarrolladas desde la educacion preescolar y cada vez
m
as las escuelas de educaci
on primaria y secundaria se mueven hacia un modelo
de educaci
on que se apoya en materiales didacticos con alto contenido de colores
como herramienta para mejorar el aprendizaje de los ni
nos.
Seg
un la fuente que se consulte, el porcentaje de la poblacion varonil mexicana que padece de daltonismo vara entre 4 y 8 por ciento, es decir, entre 2
y 4 millones y medio de hombres en Mexico a diferencia del 0.4 por ciento de
las mujeres que sufren de este trastorno visual que se caracteriza por la nula
habilidad de identificar cierto tipo de colores o confundirlos con otros, en espe
cial el rojo y el verde. Este
defecto es genetico aunque tambien puede adquirirse
por una enfermedad ocular o sistemica, e incluso por un traumatismo o uso de
alg
un medicamento.
Muchas de las personas que padecen este trastorno visual no se someten
a ninguna prueba para detectarlo y algunas se enteran en la adultez cuando
alg
un evento pone en evidencia la posibilidad de padecer daltonismo. Aunque el
daltonismo no imposibilita a quien lo padece de tener una vida normal en el da
a da, en la poblaci
on estudiantil representa un obstaculo mas a superar para
poder aprender al mismo ritmo que los demas y muchas veces provoca que los
estudiantes tengan un desempe
no academico menor al esperado.
Actualmente en las escuelas de nivel preescolar y basico no se llevan a cabo
pruebas para detectar a los ni
nos con daltonismo para concienciar a los profesores acerca de este trastorno y puedan ajustar los metodos de ense
nanza para que
todos los ni
nos, incluidos aquellos con daltonismo, puedan aprender al mismo
ritmo y no suponga un obst
aculo mas para el menor.

1.1.

CAPITULO 1. PLANTEAMIENTO DEL PROBLEMA

Objetivo

Brindar una herramienta que permita llevar a cabo pruebas rapidas para
detectar los casos de daltonismo entre la poblacion estudiantil de las escuelas
de nivel b
asico para que estos alumnos puedan se canalizados o se les recomiende asistir a una consulta con un oftalmologo para confirmar el diagnostico; y
orientar a los profesores acerca de que es daltonismo y como afecta la vida de
una persona para que puedan ajustar las actividades en el salon de clases para
que no representen una dificultad para los alumnos con daltonismo.

1.2.

Motivaci
on

En la materia de Taller de investigacion II se nos presenta la oportunidad

de realizar un proyecto en el que llevemos a la practica conocimientos de nuestra
area de estudio mientras desarrollamos nuevas aptitudes, pero tambien se
presenta la ocasi
on de realizar un proyecto que genere un impacto en el entorno
social en el que nos encontramos y vivimos a diario. La motivacion para este
proyecto surge del deseo de no solo generar un proyecto, sino de generar un
proyecto que sea capaz de hacer un cambio en la vida de las personas.

1.3.

Justificaci
on

Con el desarrollo de una prueba rapida para la deteccion de casos de daltonismo en las escuelas de nivel basico se lograra captar en una etapa temprana a
los ni
nos que padezcan de este trastorno de la vision y puedan tener conocimiento, tanto alumnos como profesores, acerca de como esto afectara su desarrollo
academico para que, en el caso de los profesores, puedan tomarse estrategias
que incluyan a los alumnos con este padecimiento.
La aplicaci
on podra llevarse a cabo por los mismos profesores que se encuentran frente a grupo u otra persona, quedando esto a criterio de la direccion
escolar, siempre y cuando cuente con al menos una computadora funcional.

1.4.

Impacto econ
omico

Con el desarrollo de esta prueba rapida, se evitara la movilizacion de personal

del sector salud para realizar las pruebas, generando un ahorro al estado. Los
padres de familia ahorraran el costo de una visita al oftalmologo, costo que en
muchas zonas de Acapulco los padres de familia no pueden sufragar o estaran
gastando dinero que estaba destinado a ropa, vivienda, alimentos u otro gasto
familiar. S
olo se les recomendara a visitar al oftalmologo cuando la prueba
resulte positiva para confirmar el diagnostico.

1.5. IMPACTO SOCIAL

1.5.

Impacto social

Conocer si uno padece una enfermedad o trastorno nos ayuda a tomar mejores decisiones en cuanto a como llevamos nuestra vida. En este caso, informar
a los estudiantes que padezcan daltonismo acerca de su condicion les permitir
a tomar decisiones informadas acerca de sus estudios academicos ademas de
que tambien afectar
a su vida fuera de la escuela. En el caso de los profesores,
informarles acerca de sus estudiantes con daltonismo les permitira adaptar sus
estrategias y materiales de ense
nanza tomando en cuenta las habilidades de estos
alumnos para que no suponga un reto extra para ellos el aprender al mismo rito
que los dem
as, adem
as de que cuando se encuentre en una situacion en la que el
estudiante no responda como se espera, el profesor podra discernir si es debido
a su condici
on de dalt
onico y tratar alguna otra alternativa o es alguna otra
cuesti
on Con respecto a los padres, el conocer si su hijo padece este trastorno
o no, podr
a ayudarles a decisiones sobre la educacion y vida de su hijo; tomar
alguna precauci
on que consideren necesario y ayudarle en su desenvolvimiento
en el mundo.

CAPITULO 1. PLANTEAMIENTO DEL PROBLEMA

Captulo 2

Marco te
orico
Se puede definir un sistema inteligente como un Sistema que presenta, como
principal caracterstica, su capacidad de adaptacion a condiciones variables de
su entorno, en pos del cumplimiento de sus objetivos. Para ello debe poseer tres
capacidades b
asicas:
1. De Razonar, para obtener conclusiones y, de ah, tomar sus propias decisiones.
2. De Aprender, para adquirir nuevos conocimientos, a partir de sus experiencias.
3. De Interactuar con otros Sistemas Inteligentes, mediante la comunicacion
y el entendimiento.
De (1) y (2) surge la capacidad suprema de todo sistemas inteligentes, de
Generalizar, para resolver bien situaciones no presentadas durante su proceso de
aprendizaje. Comprende la formacion de conceptos: transicion de una descripci
on particular de un objeto a una descripcion conceptual. Se da por supuesto
que el Sistema Inteligente posee, al menos, una mnima capacidad de memorizar,
la que es un imprescindible complemento de todas estas capacidades. De todo
lo anterior devienen las caractersticas principales de los sistemas inteligentes,
que pueden ser llamadas esenciales, a las que se agregan otras, denominadas
caractersticas deseables:
Esenciales
Razonamiento: para obtener conclusiones y, de ah, tomar sus propias
decisiones.
Aprendizaje: para adquirir nuevos conocimientos, a partir de sus experiencias.
Interacci
on con otros Sistemas Inteligentes, mediante la comunicacion
y el entendimiento.
9


CAPITULO 2. MARCO TEORICO

10

Generalizacion: para resolver bien situaciones no presentadas durante

su proceso de aprendizaje.
Memoria: como imprescindible complemento de las demas capacidades.
Deseables
Robustez: para poder continuar operando bien con da
nos parciales.
Reproduccion: para poder mejorar generacionalmente.
Que es el daltonimo? El daltonimo es pocas palabras una afectacion genetica que deviene en la ceguera ante ciertos colores, lo mas com
un es que sea
una un ceguera ante el rojo y el verde[Pierce, 2009] pero tambien existen otras

variantes que afectan la percepcion de otros colores. Esta

enfermedad afecta predominantemente a los hombres. La causa por la cual la padecen principalmente
los hombres, se debe a una mutacion en genes del cromosoma X, esto ocasiona
que sea sumamente difcil que la mujer lo padezca, ya que sus dos cromosomas
X deben tener la mutacion, mientras que el varon al tenerlos XY esta mas predispuesto.
La idea de utilizar aplicaciones de software en el campo de la medicina no

es reciente. Este
concepto se ha estado desarrollando casi desde el comienzo del
desarrollo del software mismo. Su utilizacion ha facilitado mucho el diagnostico medico y el desarrollo de nuevas tecnicas de tratamiento y procedimientos
medicos. Sin embargo, con la aparicion de los telefonos inteligentes, la creacion
de m
as y m
as aplicaciones moviles que de alg
un modo tratan de ser una herramienta en el tratamiento, monitoreo o diagnostico de alguna enfermedad es
cada vez m
as com
un y con el aumento del poder adquisitivo de la poblacion
est
an m
as cerca de las personas.
Debido a esto, en la actualidad el alcance una aplicacion movil es muy grande
debido al que un buen porcentaje de la poblacion posee ya un telefono capaz de
ejecutarlas, con esto en mente han surgido aplicaciones sencillas para de alg
un
modo aumentar la conciencia en las personas acerca de algunos padecimientos.
Estudiantes de la Universidad Iberoamericana crearon una aplicacion movil destinada a Windows phone 8[Vargas Hernandez, 2013] que utiliza la camara del
dispositivo para tomar una fotografa y despues compararla con la informacion
mantenida en una base de datos para desplegar en pantalla en nombre del color

y un c
odigo ayudando a las personas a identificar colores y tonalidades. Esto
es de gran utilidad para personas que poseen alg
un grado de daltonismo o han
sufrido alguna afectacion en la vista que les dificulte diferenciar tonos o colores.
En Mexico, un 8 por ciento de los hombres confunden las gamas cromaticas,
frente a un 2 por ciento en mujeres. Seg
un los expertos es un mal menor, aunque hay casos que pueden generar mucha frustracion, como los de aquellos que
quieren ser pilotos de aviacion. Esta ceguera hacia el rojo y el verde afecta a un

11
8 por ciento de la poblaci
on masculina de todo el mundo. En America Latina
1 de cada 12 hombres es dalt
onico y aquneu este defecto es genetico tambien
puede adquirirse por una enfermedad ocular o sistemica, e incluso por un traumatismo o uso de alg
un medicamento.[Munaiz, 2012]
Por ello grandes empresas como Google mencionan la importancia que se
tiene cuando una persona con daltonismo usa alguna aplicacion, y como es importante que sus sistema Android sea u
til y agradable para cada uno de sus
usuarios, por lo que versi
on tras version a
naden mas ajustes de accesibilidad
para personas con estos problemas. Android Lollipop probablemente sea una
de las mejores actualizaciones para aquellas personas que sufran de daltonismo, puesto que dispone un modo de correccion de pantalla para daltonicos. La
tecnologa de los telefonos inteligentes con el paso del tiempo ha permitido que
existan aplicaciones de realidad aumentada que permitan simular la vista de
alguien con daltonismo.
A pesar de su condici
on, una persona que nace con daltonismo no tiene problemas visuales y es poco probable que desarrolle enfermedades degenerativas
como miopa, astigmatismo o cataratas en comparacion de alguien que no tiene
el padecimiento. Sin embargo, estos pacientes tienen algunas limitaciones para
desarrollar una actividad laboral; las personas con discromatopsia, es decir con
la discapacidad para ver uno o varios colores, no pueden ejercer carreras en las
cuales es indispensable distinguir diversas tonalidades, como piloto aviador, dise
nador gr
afico o textil ni en actividades militares o de seguridad.[MM, 2011]
Sin embargo, las afectaciones permanecen, recientemente Samsung desarrollo
un software que ajusta en tiempo real los colores de la pantalla del telefono para
hacerlos m
as visibles a las personas daltonicas.[Zahumenszky, 2014] la aplicaci
on se basa en la capacidad de las pantallas OLED de ajustar el tono de cada
pixel de manera independiente. As, si activamos el modo para personas que no
distinguen bien los colores verde y rojo, toda la interfaz, y hasta lo que vemos
a traves de la c
amara se ajusta en consonancia.
Al no existir una cura o tratamiento para el daltonismo, mismo que no
altera la calidad visual de los pacientes, se brinda orientacion con la finalidad
de que se integren al mercado laboral en diversas carreras que no necesitan que
el trabajador distinga los colores. Algunos medicamentos, como los usados para
el tratamiento de la artritis reumatoide, pueden causar daltonismo y deteriorar
a la m
acula, lo que provoca alteracion de la agudeza y del campo visual, un
da
no irreparable a la vista.

12

CAPITULO 2. MARCO TEORICO

Captulo 3

Metodologa
3.1.

Introducci
on

Con el objetivo de cubrir todos los aspectos relevantes para el desarrollo,

la recopilacip
on de la informaci
on debera tener elementos que nos permitan tener una visi
on general y luego m
as especfica sobre la problematica que se esta
abordando con este proyecto, teniendo en cuenta que las variables del enotrno
pueden cambiar durante el desarrollo del proyecto dicha informacion debera poder ser utilizada para realizar proyecciones a corto plazo, por lo menos cubriendo
el tiempo de desarrollo del proyecto. La investigacion realizada marcara el inicio
del proyecto y ser
a actualizda si se considera necesario ademas de que puede
expandirse o abarcar nuevos objetivos, si as se decide, durante los seis meses
que durar
a el desarrollo del proyecto.

Al final de la investigaci
on deberemos haber alcanzado tres metas: La primera es haber recabado toda la informacion ecesaria para obtener una descripcion
de la situaci
on actual sobre los diagnosticos de daltonismo en la poblacion estudiantil de nivel b
asico del puerto de Acapulco, la segunda generar una imagen
sobre el uso de los equipos de c
omputo y los servicios de tecnologas de la informaci
on con los que se cuenta en las escuelas de nivel basico del puerto para
poder tener una idea de el ambiente objetivo de nuestro proyecto y hacer las
correciones pertinentes. La tercer meta es hacernos con la informacion necesaria
para desarrollar el software que nos permitira realizar la prueba rapida para
detecci
on del daltonismo.
13

CAPITULO 3. METODOLOGIA

14

3.2.

Metodologa para el desarrollo de una prueba r

apida para la detecci
on de casos de daltonismo en el nivel de educaci
on b
asica.

Debido a que el resultado esperado al terminar el proyecto es contar con

un producto de software, utilizaremos una de las metodologas de desarrollo de
software que est
an disponibles para aplicarlo en nuestro proyecto. De las diferentes metodologas existentes consideramos 3: El modelo de cascada, prototipos
y el modelo de desarrollo rapido de aplicaciones (RAD) decantandonos pro la
primera, el modelo de cascada, debido a que todos lso integrantes estan mas
familiarizados con ella y a la facilidad y sencillez de su aplicacion y seguimiento.

Este
modelo cuenta con 6 etapas o fases.

3.2.1.

An
alisis de requisitos:

Para lograr identificar todos los requerimientos primero necesitamos conocer todas las necesidades que existen. Para ello, realizaremos una investigacion
exploratoria para introducirnos en el tema y realizar un primera cercamiento
seguida de una investigacion descriptiva que nos permita analizar y describir la
situacion actual en la que se encuentra el diagnostico de casos de daltonismo
en la poblaci
on estudiantil de nivel basico en Acapulco y sobre el desarrollo de
software.
Investigaci
on exploratoria:
Nuestro conocimiento del tema es tan vago e impreciso que nos impide sacar
las m
as provisorias conclusiones sobre que aspectos son relevantes y cuales no,
se requiere en primer termino explorar e indagar, para ello que se utilizara la
investigaci
on exploratoria. Para explorar este tema relativamente desconocido
se dispone de un amplio espectro de medios y tecnicas para recolectar datos en
diferentes ciencias como son la revision bibliografica especializada, entrevistas y
cuestionarios, observacion participante y no participante y seguimiento de casos.
La investigaci
on exploratoria terminara cuando, a partir de los datos recolectados, haya sido posible crear un marco teorico y epistemologico lo suficientemente fuerte como para determinar que factores son relevantes al problema y
por lo tanto deben ser investigados.
En pocas ocasiones un estudio exploratorio constituye un fin en s mismo,
sino que establece el tono para investigaciones posteriores y se caracteriza por
ser m
as flexible en su metodologa, es mas amplios y disperso, implica un mayor
riesgo y requierir
a de paciencia, serenidad y receptividad por parte del investigador. El estudio exploratorio se centrara en descubrir. La investigacion historica
y la investigaci
on documental son de tipo exploratorio.


DE CA
3.2. METODOLOGIA PARA EL DESARROLLO DE UNA PRUEBA RAPIDA
PARA LA DETECCION
La investigaci
on hist
orica trata de la experiencia pasada, describira lo que
era y representa una b
usqueda crtica de la verdad que sustenta los acontecimientos pasados. El investigador depende de fuentes primarias y secundarias las
cuales proveen la informaci
on y a las cuales el investigador debera examinar cuidadosamente con el fin de determinar su confiabilidad por medio de una crtica
interna y externa. En el primer caso verifica la autenticidad de un documento
o vestigio y en el segundo, determina el significado y la validez de los datos que
contiene el documento que se considera autentico.
A partir de los estudios exploratorios se generan las investigaciones descriptivas.
Investigaci
on descriptiva:
En un estudio descriptivo se seleccionan una serie de conceptos o variables
y se mide cada una de ellas independientemente de las otras, con el fin, precisamente, de describirlas.

Este
estudio buscar
a especificar las propiedades importantes de personas,
grupos, comunidades o cualquier otro fenomeno que tenga realacion con el
diagn
ostico de casos de daltonismo. El enfasis estara en el estudio independiente
de cada caracterstica, es posible que de alguna manera se integren la mediciones de dos o m
as caractersticas con en fin de determinar como es o como se
manifiesta dicho fen
omeno pero en ning
un momento se pretendera establecer la
forma de relaci
on entre estas caractersticas.
Su prop
osito ser
a la delimitaci
on de los hechos que conforman el problema
de investigaci
on, como:
1. Establecer las caractersticas demograficas de las unidades investigadas
(n
umero de poblaci
on, distribucion por edades, nivel de educacion, etc.).
2. Identificar formas de conducta, actitudes de las personas que se encuentran
en el universo de investigacion (comportamientos sociales, preferencias,
etc.)
3. Establecer comportamientos concretos.
4. Descubrir y comprobar la posible asociacion de las variables de investigaci
on.
5. Identifica caractersticas del universo de investigacion, se
nala formas de
conducta y actitudes del universo investigado, establece comportamientos
concretos y descubre y comprueba la asociacion entre variables de investigaci
on.
6. En investigaci
on de mercados son muy frecuentes y buscan explorar los
gustos de los consumidores, los nichos de mercado para introducir un producto nuevo, la aceptaci
on hacia la sustitucion de un producto por otro.

CAPITULO 3. METODOLOGIA

16

De acuerdo con los objetivos planteados, se

nalaremos el tipo de descripcion
que se propone realizar. Acude a tecnicas especficas en la recoleccion de informaci
on, como la observacion, las entrevistas y los cuestionarios. La mayora de
las veces se utiliza el muestreo para la recoleccion de informacion, la cual es
sometida a un proceso de codificacion, tabulacion y analisis estadstico.
Estos estudios describen la frecuencia y las caractersticas mas importantes
de un problema. Para hacer el estudio descriptivo habra que tener en cuenta dos
elementos fundamentales: El tama
no de muestra y el instrumento de recoleccion
de datos.
La metodologa para realizar estas unvestigaciones sera:
1. Determinar las fuentes de datos a recolectar.
a) Definir la informacion necesaria
b) Dise
nar las fases explorativas y descriptivas.
c) Especificar los procedimientos para medir y elaborar escalas.
d ) Especificar el proceso de muestreo y el tama
no de la muestra.
e) Desarrollar un plan para el analisis de los datos recabados.
2. Determinar el dise
no de la investigacion.
3. Determinar la muestra.
4. Recolectar los datos obtenidos.
5. Interpretar la informacion recabada.

3.2.2.

Especificaci
on

Es la tarea de describir detalladamente el software a ser escrito, de una forma

rigurosa. Se describir
a el comportamiento esperado del software y su interaccion
con los usuarios y/o otros sistemas. Se incluyen un conjunto de casos de uso que
describe todas las interacciones que tendran los usuarios con el software. Los
casos de uso tambien son conocidos como requisitos funcionales. Ademas de los
casos de uso, tambien contiene requisitos no funcionales o complementarios. Los
requisitos no funcionales son requisitos que imponen restricciones en el dise
no
o la implementaci
on, como, por ejemplo, restricciones en el dise
no o estandares
de calidad.
Sus caractersticas son definidas por el estandar IEEE 830-1998:
Completa: Todos los requerimientos deben estar reflejados en ella y todas
las referencias deben estar definidas.
Consistente: Debe ser coherente con los propios requerimientos y tambien
con otros documentos de especificacion.


DE CA
3.2. METODOLOGIA PARA EL DESARROLLO DE UNA PRUEBA RAPIDA
PARA LA DETECCION
Inequvoca: La redacci
on debe ser clara de modo que no se pueda mal
interpretar.
Correcta: El software debe cumplir con los requisitos de la especificacion.
Trazable: Se refiere a la posibilidad de verificar la historia, ubicacion o
aplicaci
on de un tem a traves de su identificacion almacenada y documentada.
Priorizable: Los requisitos deben poder organizarse jerarquicamente seg
un
su relevancia para el proyecto y clasificandolos en esenciales, condicionales
y opcionales.
Modificable: Aunque todo requerimiento es modificable, se refiere a que
debe ser f
acilmente modificable.
Verificable: Debe existir un metodo finito sin costo para poder probarlo.

Los requisitos se clasificar

an dentro de una de las siguientes categoras.
Requisitos de Usuarios: Necesidades que los usuarios expresan verbalmente
Requisitos del Sistema: Son los componentes que el sistema debe tener
para realizar determinadas tareas
Requisitos Funcionales: Servicios que el sistema debe proporcionar
Requisitos no funcionales: Restricciones que afectaran al sistema

3.2.3.

Dise
no del programa

Teniendo en cuenta toda la informacion que hemos recabado en la etapa

anterior y el analisis que hemos hecho de la misma, en esta etapa realizaremos el dise
no de c
omo deber
a funcionar nuestro sistema, como se comportara,
su organizaci
on interna. Aqu se define la estructura del programa. Determinaremos como funcionar
a de forma general sin entrar en detalles incorporando
consideraciones de la implementacion tecnologica, como el hardware, la red,
etc. Consistir
a en el dise
no de los componentes del sistema que dan respuesta a
las funcionalidades descritas. Generalmente se realiza en base a diagramas que
permitan describir las interacciones entre las entidades y su secuenciado.
En resumen, el dise
no del software es realmente un proceso de muchos pasos
o subprocesos que se clasifican dentro de uno mismo. En general, la actividad
del dise
no de se refiere al establecimiento de las estructuras de datos, la aquitectura general del software, representaciones de interfaz y algoritmos. El proceso
de dise
no de software traduce los requisitos a una representacion de software.
Existen herramientas libres para dise
nar software totalmente libres cuyas
caractersticas son:

CAPITULO 3. METODOLOGIA

18
Todas utilizan la notacion UML

El nivel de avance entre una y otra es notable, casi todas ofrecen como
funcionalidad:
Diagramas de caso de uso
Diagramas de clases
Diagramas de secuencia
Generaci
on de codigo en java, c++, python y php
Algunas entidad-relacion (pero ninguna lo suficientemente avanzada)
Pocas herramientas permiten ingeniera reversa, y si lo hacen solo es de
lenguajes tipo java o c++.

Herramientas para dise

nar software:
Use Case Maker, solo documentar casos de usos y requerimientos relativos.
ObjectBuilder, permite documentar clases, relaciones, metodos, etcetera.
BoUml, herramienta de dise
no UML multiplataforma, es bastante completa tiene todos los diagramas UML estandares y genera codigo.
Gaphor, mismas caracterstica que BoUml pero menos diagramas.
Taylor, es un set de plug-ins para Eclipse para modelar bajo UML, genera
y lee c
odigo Java.
Umbrello, desarrollado en C++ es parte del escritorio KDE, actualmente
u
nicamente utilizado en Linux pero ya el escritorio KDE se puede correr
en Windows por lo cual la herramienta podra ser utilizada. Rapida, ligera, sencilla de usar, no se pone lenta cuando los proyectos son enormes.
Requiere de mas opciones de generacion de documentacion de los dise
nos
modelados dentro de ella. Permite generar codigo en diversos lenguajes.
Soporta los diagramas UML estandares.
ArgoUML, desarrollado en Java es multiplataforma. Provee toda la funcionalidad desea en una herramienta para modelar bajo UML. Genera
c
odigo en varios lenguajes. Sus dise
nos son exportables a XMI y pueden
ser importados por algunos Frameworks. Tiene un depurador del dise
no
que vamos creando, el depurador sugiere soluciones o detecta incongruencias, sus mensajes son bastante claros y de mucha ayuda.


DE CA
3.2. METODOLOGIA PARA EL DESARROLLO DE UNA PRUEBA RAPIDA
PARA LA DETECCION

3.2.4.

Codificaci
on

El dise
no se traduce a c
odigo. Es la parte mas obvia del trabajo de ingeniera de software y la primera en que se obtienen resultados ((tangibles)). No es
necesariamente la etapa m
as larga ni la mas compleja aunque una especificacion
o dise
no incompletos/ambiguos pueden exigir que, tareas propias de las etapas
anteriores se tengan que realizarse en esta.
Durante la codificaci
on del proyecto se utilizaran las tecnicas de cosificacion
recomendadas. Aunque generalmente no afectan a la funcionalidad de la aplicaci
on, s contribuyen a una mejor compresion del codigo fuente. En esta fase
se tienen en cuenta todos los tipos de codigo fuente, incluidos los lenguajes de
programaci
on, de secuencias de comandos, de marcado o de consulta.
Las tecnicas de codificaci
on aqu definidas no pretenden formar un conjunto
inflexible de est
andares de codificacion. Mas bien intentan servir de gua en el
desarrollo del proyecto de software.
Las tecnicas de codificaci
on estan divididas en tres secciones:
Nombres:
El esquema de nombres es una de las ayudas mas importantes para
entender el flujo l
ogico de una aplicacion. Un nombre debe mas bien
expresar el ((que)) que el ((como)). Si evita nombres que se refieran a
la implementaci
on subyacente (sujeta a cambios), estara conservando
un grado de abstracci
on que lo simplificara todo.
El interes de poner un nombre es que la dificultad para escoger uno
adecuado puede indicar que se necesita analizar o definir con mayor
precisi
on el prop
osito de un elemento. Ponga nombres lo suficientemente largos para que sean elocuentes, pero lo bastante cortos como para que no pequen de palabrera. Desde el punto de vista de
la programaci
on, un nombre u
nico sirve solamente para diferenciar
un elemento de otro. Los nombres expresivos funcionan como ayuda
para el lector, por eso, es logico dar nombres que sean faciles de comprender. No obstante, aseg
urese de que los nombres escogidos sean
compatibles con las reglas de cada lenguaje y con los estandares.
Comentarios:
Cuando modifique el c
odigo, mantenga siempre actualizados los comentarios circundantes.
Al principio de cada rutina, resulta u
til hacer comentarios estandar,
repetitivos, que indiquen el proposito de la rutina, las suposiciones
y las limitaciones. Un comentario repetitivo podra consistir en una
breve introducci
on que explicara por que existe y que puede hacer.
Evitar a
nadir comentarios al final de una lnea de codigo, porque
lo hacen m
as difcil de leer. Sin embargo, los comentarios de final

CAPITULO 3. METODOLOGIA

20

de lnea s son apropiados al anotar declaraciones de variables. En

este caso, alinee todos los comentarios de final de lnea en la misma
posici
on de tabulacion.
Evite los comentarios recargados, como las lneas enteras de asteriscos. En su lugar, utilice espacios para separar los comentarios y el
c
odigo.
Evitar rodear un bloque de comentarios con un marco tipografico.
Puede resultar agradable, pero es difcil de mantener. Antes de la implementaci
on, quite todos los comentarios temporales o innecesarios,
para evitar cualquier confusion en la futura fase de mantenimiento.
Si necesita realizar comentarios para explicar una seccion de codigo
compleja, examine el codigo para decidir si debera volver a escribirlo.
Siempre que sea posible, no documente un codigo malo, vuelva a escribirlo. Aunque, por regla general, no debe sacrificarse el rendimiento
para hacer un codigo mas simple para el usuario, es indispensable un
equilibrio entre rendimiento y mantenibilidad.
Use frases completas cuando escriba comentarios. Los comentarios
deben aclarar el codigo, no a
nadirle ambig
uedad.
Vaya comentando al mismo tiempo que programa, porque probablemente no tenga tiempo de hacerlo mas tarde. Por otro lado, aunque
tuviera oportunidad de revisar el codigo que ha escrito, lo que parece
obvio hoy es posible que seis semanas despues no lo sea.
Evite comentarios superfluos o inapropiados, como comentarios divertidos al margen.
Usar los comentarios para explicar el proposito del codigo. No los
usarlos como si fueran traducciones interlineales.
Comente cualquier cosa que no sea legible de forma obvia en el codigo.
Para evitar problemas recurrentes, haga siempre comentarios al depurar errores y solucionar problemas de codificacion, especialmente
cuando trabaje en equipo.
Haga comentarios en el codigo que este formado por bucles o bifurcaciones l
ogicas. Se trata en estos casos de areas clave que ayudaran
a los lectores del codigo fuente.
Realizar los comentarios en un estilo uniforme, respetando una puntuaci
on y estructura coherentes a lo largo de toda la aplicacion.
Separar los comentarios de sus delimitadores mediante espacios.
Formato.
Establecer un tama
no estandar de sangra (por ejemplo, cuatro espacios) y u
selo siempre. Alinee las secciones de codigo mediante la
sangra predeterminada.


DE CA
3.2. METODOLOGIA PARA EL DESARROLLO DE UNA PRUEBA RAPIDA
PARA LA DETECCION
Use un u
nico tipo de letra cuando publique versiones impresas del
c
odigo fuente.
Alinee verticalmente las llaves de apertura y cierre donde los pares
de llaves se alinean. Tambien puede usar un estilo inclinado, en el
que las llaves de apertura aparezcan al final de la lnea y las de cierre
al principio.
Aplique una sangra al codigo en todas las lneas de construccion
l
ogica.
Establecer una longitud de lnea maxima para los comentarios y el
c
odigo. As no tendr
a que desplazarse en el editor del codigo fuente,
y conseguir
a presentaciones impresas claras.
Utilizar espacios antes y despues de los operadores siempre que eso
no altere la sangra aplicada al codigo.
Use espacios en blanco para proporcionar indicaciones organizativas
del c
odigo fuente. As, creara ((parrafos)) de codigo, que ayudaran al
lector a comprender la segmentacion logica del software.
Cuando tenga que dividir una lnea en varias, aclare que el codigo
sigue en la lnea de m
as abajo mediante un operador de concatenacion
colocado al final de cada lnea, y no al principio.
Siempre que sea posible, no coloque mas de una instruccion por lnea.
Una excepci
on es un bucle.
Dividir las secciones de codigo grandes y complejas en otras mas
peque
nas y comprensibles.

3.2.5.

Pruebas

Esta
ser
a una de las etapas m
as crticas de todo el proceso ya que en esta
estapa se realizan todas las pruebas que sean necesarias paara asegurar la funcionalidad total y que todo se lleve a cabo como fue dise
nado el sistema. Si
es detectada alguan falla, deberemos regresarnos a las etapas anteriores para
repararlos y poder continuar con las pruebas hasta que todo este correcto.
Las pruebas consideradas para realizarse son las siguientes:
Prueba Unitaria:
Objetivo de la Prueba: Se focaliza en ejecutar cada modulo (o unidad
minima a ser probada, ej = una clase) lo que provee un mejor modo de
manejar la integraci
on de las unidades en componentes mayores. Busca
asegurar que el c
odigo funciona de acuerdo con las especificaciones y que
el m
odulo l
ogico es v
alido.
Descripci
on de la Prueba: Particionar los modulos en pruebas en unidades
l
ogicas f
aciles de probar. Por cada unidad hay que definir los casos de

CAPITULO 3. METODOLOGIA

22

prueba (pruebas de caja blanca). Para esto los casos de prueba deben
dise
narse de forma tal que se recorran todos los caminos de ejecucion
posibles dentro del codigo bajo prueba; por lo tanto el dise
nador debe
construirlos con acceso al codigo fuente de la unidad a probar. Los aspectos
a considerar son los siguientes:
Rutinas de excepcion.
Rutinas de error.
Manejo de parametros.
Validaciones.
Valores v
alidos.
Valores lmites.
Rangos.
Mensajes posibles.
Tecnica: Comparar el resultado esperado con el resultado obtenido. Si
existen errores, reportarlos.
Criterio de Completitud:
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identificaron han sido tenidos en cuenta.
Prueba de Regresi
on:
Objetivo de la Prueba: Determinar si los cambios recientes en una parte
de la aplicaci
on tienen efecto adverso en otras partes.
Descripci
on de la Prueba: En esta prueba se vuelve a probar el sistema
a la luz de los cambios realizados durante las correciones, mantenimiento
o desarrollo de la nueva version del sistema buscando efectos adversos en
otras partes.
Tecnica: La prueba de regresion es una nueva corrida de casos de prueba
previos. Se requiere de polticas para ser creada la prueba de regresion y
decidir que casos de prueba incluir, para probar eficientemente. La prueba
de viejas funcionalidades es mas importante que la de nuevas funcionalidades. Aquellos casos de uso (y los casos de prueba asociados) que descubren
defectos tempranamente deben ser incluidos en la prueba de regresion.
Criterio de Completitud:
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identificaron han sido tenidos en cuenta.


DE CA
3.2. METODOLOGIA PARA EL DESARROLLO DE UNA PRUEBA RAPIDA
PARA LA DETECCION
Pruebas de GUI:
Objetivo de la Prueba: Verifica lo siguiente:
La navegaci
on a traves de los objetos de la prueba reflejan las funcionalidades y requisitos, se realiza una navegacion ventana por ventana,
usando los modos de acceso (tabuladores, movimientos del mouse, teclas r
apidas, etc)
Los objetos de la ventana y caractersticas, tales como men
us, medidas, posiciones, estados y focos se verifican conforme a los estandares.
Descripci
on de la Prueba: La prueba de interfaz de usuario verifica la interacci
on del usuario con el software. El objetivo es asegurar que la interfaz
tiene apropiada navegaci
on a traves de las diferentes funcionalidades. Adicionalmente, las pruebas de interfaz aseguran que los objetos de la interfaz
a ser probada se encuentra dentro de los estandares de la industria.
Tecnica: Pruebas de crear / modificar cada ventana para verificar la adecuada navegaci
on y estado de los objetos.
Criterio de Completitud:
Cada ventana elegida sera totalmente verificada y comparada con
similares en el mercado logrando una buena aceptacion dentro del
est
andar.
Pruebas Funcionales:
Objetivo de la Prueba: Se asegura la trabajo apropiado de los requisitos
funcionales, incluyendo la navegacion, entrada de datos, procesamiento y
obtenci
on de resultados.
Descripci
on de la Prueba: Las pruebas Funcionales deben enfocarse en los
requisitos funcionales, las pruebas pueden estar basadas directamente en
los Casos de Uso, y las reglas del diagnostico del daltonismo. Las metas
de estas pruebas son:
Verificar la apropiada aceptacion de datos.
Verificar el procesamiento y recuperacion y la implementacion adecuada de las reglas para el diangostico del daltonismo.
Este tipo de pruebas est
an basadas en tecnicas de caja negra, que es,
verificar la aplicaci
on (y sus procesos internos) mediante la interaccion con
la aplicaci
on va GUI y analizar la salida (resultados). Lo que se identifica
a continuaci
on es un dise
no preliminar de las pruebas recomendadas para
cada aplicaci
on.
Tecnica: Se ejecuta cada caso de uso, flujo de caso de uso, o funcion,
usando datos v
alidos e inv
alidos, para verificar lo siguiente:

CAPITULO 3. METODOLOGIA

24

Que los resultados esperados ocurran cuando se usen datos validos.

Que sean desplegados los mensajes apropiados de error y precaucion
cuando se usan datos invalidos.
Que se aplique apropiadamente cada regla del diagnostico del daltonismo.
Criterio de Completitud:
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identificaron han sido tenidos en cuenta.
Prueba de Usabilidad
Objetivo de la Prueba: Determinar la usabilidad del sistema.
Descripci
on de la Prueba: Determina cuan bien el usuario podra usar y
entender la aplicacion. Identifica las areas de dise
no que hacen al sistema
de difcil uso para el usuario. La prueba de usabilidad detecta problemas
relacionados con la conveniencia y practicidad del sistema desde el punto
de vista del usuario.
Tecnica: Verificar que la aplicacion no presenta los siguientes problemas
de usabilidad tpicos:
El sistema es demasiado complejo y difcil de usar.
Es difcil instalar y entender el sistema.
La recuperacion de errores es pobre y los mensajes de error no tienen
significado.
La sintaxis de los comandos es difcil de aprender y recordar.
El sistema obliga al usuario a recordar formatos y secuencias fijas.
Los procedimientos no son simples ni obvios.
El sistema no tiene instrucciones de ayuda por computadora y tiene
manuales pobres.
Los diagramas, pantallas, reportes y graficos son de calidad y apariencia pobre.
El sistema carece de herramientas de construccion adecuadas y requiere m
ultiples comandos.
La l
ogica y conveniencia de los botones, switches, displays y mensajes
de ayuda deben ser testeados. (La prueba de usabilidad puede ser
conducida por un grupo separado si es posible.
Se deben crear casos de prueba para comprobar que se puede operar en el
sistema de forma adecuada.


DE CA
3.2. METODOLOGIA PARA EL DESARROLLO DE UNA PRUEBA RAPIDA
PARA LA DETECCION
Criterio de Completitud:
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identificaron han sido tenidos en cuenta.
Prueba de Campo
Objetivo de la Prueba: Correr el sistema en el ambiente real para encontrar
errores y validar el producto contra sus especificaciones originales.
Descripci
on de la Prueba: Realizar un subconjunto valido de pruebas de
sistema.
Tecnica: Determinar que pruebas de sistema seran corridas para validar
el sistema en producci
on.
Criterio de Completitud:
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identificaron han sido tenidos en cuenta.

3.2.6.

Documentaci
on

En esta etapa se llevar

a a cabo la realizacion del manual de usuario, y posiblemente un manual tecnico con el proposito de mantenimiento futuro y ampliaciones al sistema. Las docuemtnacion se inicia ya en el primera etapa y se
realiza en cada una de ellas y finaliza una vez terminadas las pruebas.

3.2.7.

Mantenimiento

Despues de la implementaci
on y verificacion, habra opcaciones en las que se
necesite realizar arreglso menores o surjan situaciones que no fueron previstas
y tampoco aparecieron durante la etapa de pruebas. En esta etapa se realizan
un mantenimiento correctivo (resolver errores) y un mantenimiento evolutivo
(mejorar la funcionalidades y/o dar respuesta a nuevos requisitos).
En esta etapa, sobretodo para ampliar el sistema con nuevas funciones, deben
realizarse todos proceso de desarrollo de nuevo como si se tratara de sub-etapas
1 a 7 si se quiere abordar con garantas y calidad.

26

CAPITULO 3. METODOLOGIA

Captulo 4

Pruebas y resultados
Las pruebas consideradas para realizarse son las siguientes:
Prueba Unitaria:
Objetivo de la Prueba: Se focaliza en ejecutar cada modulo (o unidad
minima a ser probada, ej = una clase) lo que provee un mejor modo de
manejar la integraci
on de las unidades en componentes mayores. Busca
asegurar que el c
odigo funciona de acuerdo con las especificaciones y que
el m
odulo l
ogico es v
alido.
Descripci
on de la Prueba: Particionar los modulos en pruebas en unidades
l
ogicas f
aciles de probar. Por cada unidad hay que definir los casos de
prueba (pruebas de caja blanca). Para esto los casos de prueba deben
dise
narse de forma tal que se recorran todos los caminos de ejecucion
posibles dentro del c
odigo bajo prueba; por lo tanto el dise
nador debe
construirlos con acceso al c
odigo fuente de la unidad a probar. Los aspectos
a considerar son los siguientes:
Rutinas de excepci
on.
Rutinas de error.
Manejo de par
ametros.
Validaciones.
Valores v
alidos.
Valores lmites.
Rangos.
Mensajes posibles.
Tecnica: Comparar el resultado esperado con el resultado obtenido. Si
existen errores, reportarlos.
Criterio de Completitud:
27

CAPITULO 4. PRUEBAS Y RESULTADOS

28

Todas las pruebas planeadas han sido ejecutadas.

Todos los defectos que se identificaron han sido tenidos en cuenta.
Prueba de Regresi
on:
Objetivo de la Prueba: Determinar si los cambios recientes en una parte
de la aplicaci
on tienen efecto adverso en otras partes.
Descripci
on de la Prueba: En esta prueba se vuelve a probar el sistema
a la luz de los cambios realizados durante las correciones, mantenimiento
o desarrollo de la nueva version del sistema buscando efectos adversos en
otras partes.
Tecnica: La prueba de regresion es una nueva corrida de casos de prueba
previos. Se requiere de polticas para ser creada la prueba de regresion y
decidir que casos de prueba incluir, para probar eficientemente. La prueba
de viejas funcionalidades es mas importante que la de nuevas funcionalidades. Aquellos casos de uso (y los casos de prueba asociados) que descubren
defectos tempranamente deben ser incluidos en la prueba de regresion.
Criterio de Completitud:
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identificaron han sido tenidos en cuenta.
Pruebas de GUI:
Objetivo de la Prueba: Verifica lo siguiente:
La navegacion a traves de los objetos de la prueba reflejan las funcionalidades y requisitos, se realiza una navegacion ventana por ventana,
usando los modos de acceso (tabuladores, movimientos del mouse, teclas r
apidas, etc)
Los objetos de la ventana y caractersticas, tales como men
us, medidas, posiciones, estados y focos se verifican conforme a los estandares.
Descripci
on de la Prueba: La prueba de interfaz de usuario verifica la interacci
on del usuario con el software. El objetivo es asegurar que la interfaz
tiene apropiada navegacion a traves de las diferentes funcionalidades. Adicionalmente, las pruebas de interfaz aseguran que los objetos de la interfaz
a ser probada se encuentra dentro de los estandares de la industria.
Tecnica: Pruebas de crear / modificar cada ventana para verificar la adecuada navegaci
on y estado de los objetos.
Criterio de Completitud:

29
Cada ventana elegida sera totalmente verificada y comparada con
similares en el mercado logrando una buena aceptacion dentro del
est
andar.
Pruebas Funcionales:
Objetivo de la Prueba: Se asegura la trabajo apropiado de los requisitos
funcionales, incluyendo la navegacion, entrada de datos, procesamiento y
obtenci
on de resultados.
Descripci
on de la Prueba: Las pruebas Funcionales deben enfocarse en los
requisitos funcionales, las pruebas pueden estar basadas directamente en
los Casos de Uso, y las reglas del diagnostico del daltonismo. Las metas
de estas pruebas son:
Verificar la apropiada aceptacion de datos.
Verificar el procesamiento y recuperacion y la implementacion adecuada de las reglas para el diangostico del daltonismo.
Este tipo de pruebas est
an basadas en tecnicas de caja negra, que es,
verificar la aplicaci
on (y sus procesos internos) mediante la interaccion con
la aplicaci
on va GUI y analizar la salida (resultados). Lo que se identifica
a continuaci
on es un dise
no preliminar de las pruebas recomendadas para
cada aplicaci
on.
Tecnica: Se ejecuta cada caso de uso, flujo de caso de uso, o funcion,
usando datos v
alidos e inv
alidos, para verificar lo siguiente:
Que los resultados esperados ocurran cuando se usen datos validos.
Que sean desplegados los mensajes apropiados de error y precaucion
cuando se usan datos invalidos.
Que se aplique apropiadamente cada regla del diagnostico del daltonismo.
Criterio de Completitud:
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identificaron han sido tenidos en cuenta.
Prueba de Usabilidad
Objetivo de la Prueba: Determinar la usabilidad del sistema.
Descripci
on de la Prueba: Determina cuan bien el usuario podra usar y
entender la aplicaci
on. Identifica las areas de dise
no que hacen al sistema
de difcil uso para el usuario. La prueba de usabilidad detecta problemas
relacionados con la conveniencia y practicidad del sistema desde el punto
de vista del usuario.

CAPITULO 4. PRUEBAS Y RESULTADOS

30

Tecnica: Verificar que la aplicacion no presenta los siguientes problemas

de usabilidad tpicos:
El sistema es demasiado complejo y difcil de usar.
Es difcil instalar y entender el sistema.
La recuperacion de errores es pobre y los mensajes de error no tienen
significado.
La sintaxis de los comandos es difcil de aprender y recordar.
El sistema obliga al usuario a recordar formatos y secuencias fijas.
Los procedimientos no son simples ni obvios.
El sistema no tiene instrucciones de ayuda por computadora y tiene
manuales pobres.
Los diagramas, pantallas, reportes y graficos son de calidad y apariencia pobre.
El sistema carece de herramientas de construccion adecuadas y requiere m
ultiples comandos.
La l
ogica y conveniencia de los botones, switches, displays y mensajes
de ayuda deben ser testeados. (La prueba de usabilidad puede ser
conducida por un grupo separado si es posible.
Se deben crear casos de prueba para comprobar que se puede operar en el
sistema de forma adecuada.
Criterio de Completitud:
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identificaron han sido tenidos en cuenta.
Prueba de Campo
Objetivo de la Prueba: Correr el sistema en el ambiente real para encontrar
errores y validar el producto contra sus especificaciones originales.
Descripci
on de la Prueba: Realizar un subconjunto valido de pruebas de
sistema.
Tecnica: Determinar que pruebas de sistema seran corridas para validar
el sistema en produccion.
Criterio de Completitud:
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identificaron han sido tenidos en cuenta.

Bibliografa
[MM, 2011] MM, R. H. (2011). El daltonismo en hombres es cada vez mas
frecuente. Reporteros hoy.
[Munaiz, 2012] Munaiz, C. (2012). Daltonismo, una enfermedad masculina.
Vanguardia.
[Pierce, 2009] Pierce, B. A. (2009). Genetica: Un enfoque conceptual. Ed. Medica Panamericana.
[Vargas Hern
andez, 2013] Vargas Hernandez, I. (2013). La ibero crea app para
dalt
onicos. CNNExpansi
on.
[Zahumenszky, 2014] Zahumenszky, C. (2014). Samsung dise
na una app para
dalt
onicos basada en pantallas oled. Gizmodo.

31