Una breve demostración de la aplicación de la Ingeniería del Software a un proyecto de trabajo de grado.

1. Desarrollo de un Software de reconocimiento
de colores de objetos en Imágenes Digitales
orientado a personas con Daltonismo del tipo
Deuteranomalía
Autores: Cristhian Caicedo
Manuel Pérez

2. Resumen del problema
La mayor cantidad de información
que puede obtener un ser humano
proviene de la adquisición directa del
sentido de la visión, mediante la cual se
puede percibir el entorno físico que le
rodea y los elementos que lo componen.
Estos elementos poseen
interrelaciones que permiten realizar una
distinción o comparación entre uno o más
de estos; un ejemplo claro es la relación
presente entre un objeto y su color.
Los colores de los globos es el único atributo que
permite distinguir los unos de los otros

3. Resumen del problema
En la actualidad, existen una diversidad de
maneras de representar gráficamente este
entorno, dentro de las cuales se encuentran las
imágenes digitales, cuya presencia en la vida
cotidiana ha incrementado con el pasar de los
años.
No obstante, algunas personas no poseen
la capacidad de detectar una o más
características contenidas en imágenes, como
por ejemplo, los colores. Tal es el caso de
aquellas que padecen de daltonismo o ceguera
del color.
Esta discapacidad limita el reconocimiento
de colores y dificulta la distinción entre ellos,
reduciendo el espectro de colores que puede
percibir un individuo.
Comparación de la percepción cromática entre
varios tipos de daltonismo

4. Objetivo General
Desarrollar un software de
reconocimiento de colores de objetos
mediante el procesamiento de imágenes
digitales para mejorar la percepción
cromática a las personas que padecen de
deuteranomalía.
Resultado esperado:
Mejorar artificialmente su percepción
cromática respecto a las imágenes digitales,
para que así puedan interpretar
correctamente la información que contienen
éstas dentro de su contexto.
Técnica para el procesamiento de imágenes
digitales: Segmentación basada en el color

5. Objetivos Específicos
● Determinar el espectro del color y los colores
de confusión correspondientes a las personas
con deuteranomalía
● Establecer los requerimientos funcionales y no
funcionales del software
● Analizar los métodos y técnicas existentes en
la librería OpenCV orientados a detectar los
colores de un objeto en una imagen digital
● Desarrollar los algoritmos para la detección de
colores de un objeto en una imagen digital
● Verificar los algoritmos para la detección de
colores de objetos en una imagen digital.
Espectro del color que servirá como punto de
partida para la determinación de los colores
afectados en la deuteranomalía

6. Ciclo de vida del
Software
Modelo en cascada puro:
Es un ciclo de vida que admite iteraciones,
en donde después de cada etapa se realiza una o
varias revisiones para comprobar si se puede
pasar a la siguiente. Es un modelo rígido, poco
flexible, y con muchas restricciones.
Es un ciclo adecuado para los proyectos
en los que se dispone de todos los
requerimientos al comienzo, para el desarrollo
de un producto con funcionalidades conocidas o
para proyectos, que aun siendo muy complejos,
se entienden perfectamente desde el principio.
Diagrama del modelo en cascada puro con sus
etapas e interacciones entre sí

7. Ciclo de vida del
Software
Razones para usar el modelo en cascada puro:
● Trabaja de acuerdo a una planificación
sencilla
● No justifica un modelo de gestión más
elaborado
● Se dispone de la mayoría de los
requerimientos al inicio del proyecto
● No requiere un personal altamente
calificado para entregar un producto de
alta calidad
● Se dispone de bastante tiempo para la
corrección de cualquier error
A partir del ciclo de vida lineal nace el modelo en
cascada puro

8. Etapas del ciclo de vida de la Ingeniería de Requerimientos
I) Elicitación
II) Negociación
IV) Verificación y Validación
III) Especificación
● Tormenta de ideas
● Investigación documental
● Definición requerimientos
● Debate de preferencias
● Estudio de la factibilidad
● Modelado inicial del sistema
● Especificación de
requerimientos
● Prototipo
● Revisión de los requerimientos
● Medición de requerimientos

9. Metodología Agile Unified Process (AUP)
Esta metodología fue desarrollada en
septiembre de 2005 por Scott Ambler y es una
versión simplificada del Proceso Racional
Unificado (RUP). El proceso unificado ágil se
preocupa especialmente de la gestión de riesgos y
propone que aquellos elementos con alto riesgo
tengan prioridad en el proceso de desarrollo y
sean abordados en etapas tempranas del mismo.
En el proceso unificado ágil se establecen
cuatro fases que transcurren simultáneamente,
estas son: la iniciación, la elaboración, la
construcción y la transición.
Etapas de la metodología AUP

10. Fase I: La Iniciación
En esta fase se obtiene una comprensión
común entre el cliente y el equipo de
desarrollo, de este modo se podrá identificar el
alcance inicial del proyecto.
Como finalidad de esta fase, se tiene la
comprensión de la problemática y el
planteamiento inicial de una solución, gracias a
la generación de una gran variedad de puntos
de vistas del problema, producto de la
aplicación de las técnicas utilizadas en la
primera etapa del ciclo de vida de la ingeniería
de requerimientos: la elicitación de
requerimientos.
Representación gráfica de la obtención de una
idea generada en una tormenta de ideas

11. Fase I: La Iniciación
En esta etapa se pretende usar la técnica
de investigación documental, cuya finalidad es
comprender a profundidad los factores
relacionados al daltonismo del tipo llamado
deuteranomalía, para así determinar el
espectro del color y los colores de confusión
correspondientes a las personas que padecen
esta discapacidad.
Por otra parte, se usarán las técnicas de
tormenta de ideas y definición de
requerimientos, de tal manera que sea posible
establecer unos requerimientos funcionales y
no funcionales iniciales del software,
mediante el uso de un documento con un
formato especial para esto.
Posteriormente, estos requerimientos
irán tomando mejor forma en las siguientes
etapas del ciclo de vida de la ingeniería de
requerimientos.

12. Tormenta de ideas
➔ Elegir el objeto de estudio:
◆ Imágenes digitales
➔ Determinar el área de aplicación más apta y
adecuada a la problemática:
◆ Procesamiento de imágenes digitales
➔ Plantear un modelo completo hipotético del
sistema
◆ Definir requerimientos iniciales
➔ Investigar antecedentes
◆ Estudios científicos
◆ Estudios de muestreo
➔ Comprensión del dominio
◆ Conceptos y términos fundamentales
◆ Tipos y subtipos
➔ Recursos informáticos disponibles
◆ API's de interés
◆ Libros y manuales
Investigación documental
Etapa I: Elicitación

13. Definición de
requerimientos
Esta actividad tiene como
objetivo la redacción de un listado
de características que espera el
cliente que tenga el sistema. El
documento se redacta para
mejorar la comprensión entre el
Usuario y el Cliente.
Cabecera del documento de definición de
requerimientos

14. Lista de requerimientos funcionales establecidos en el documento de definición de requerimientos

15. Fase II: La Elaboración
Para esta etapa el enfoque es
profundizar en la comprensión de los
requisitos del sistema y validar la
arquitectura del software para realizar las
mejoras pertinentes.
Ya estando en la fase de negociación
del ciclo de vida de la ingeniería de
requerimientos, se realizaron debates acerca
de las herramientas y tecnologías disponibles
que sean más favorables para el desarrollo
del software.
Adicionalmente, como parte del
análisis y diseño del sistema, se realiza la
especificación de los requerimientos que
deberá tener el primer software funcional a
construir. Por lo que cabe mencionar que
esta fase de la metodología abarca más de
una etapa del ciclo de vida de la ingeniería de
requerimientos.
Debate sobre las tecnologías disponibles

16. Fase II: La Elaboración
Luego de obtener la definición
inicial de los requerimientos gracias a la
etapa de elicitación, se debe proceder
con las siguientes etapas del ciclo de vida
de la ingeniería de requerimientos.
Por tal motivo se debe realizar la
especificación de los requerimientos
definidos anteriormente y la validación
de los mismos para así poder establecer
una definición completa y consistente de
los requerimientos funcionales y no
funcionales del softwareOpenCV y GTK como librerías a utilizar en el desarrollo
del software

17. Debate de preferencias
➔ Establecer el alcance del sistema. Ej.:
◆ Entradas y salidas
◆ Plataformas a nivel de:
● Hardware
● Software
➔ Elegir el tipo de anomalía:
◆ Deuteranomalia
➔ Elegir las herramientas de software y
frameworks más favorables:
◆ OpenCV
◆ PyGTK
➔ Analizar el rendimiento apropiado
➔ Evaluar la disposición y proporción de
ciertos recursos:
◆ Tiempo
◆ Capital intelectual
➔ Evaluar la operatividad e interoperabilidad
➔ Facilidad de desarrollo del sistema
Estudio de la factibilidad
Etapa II: Negociación

18. Modelado inicial
del sistema
Diagrama de transición de estados
para describir el funcionamiento de
la interfaz gráfica de usuario del
sistema
Etapa III: Especificación
Diagrama de transición de estados

19. Especificación de
requerimientos
Una vez se hayan definidos los
requerimientos, se realiza una
especificación técnica de los
mismos, en la cual se menciona a
detalle las actividades que
determinarán si el requisito fue
cumplido o no.
Documento de especificación de requerimientos

20. Listado de especificación de requerimientos
Construir una interfaz gráfica para el manejo del
software
1. Desarrollar las ventanas de la interfaz
a. Una ventana principal
b. Una ventana para tomar la foto
c. Una ventana para la navegación entre
archivos
d. Una ventana para la imagen de respuesta
e. Una ventana que contenga una breve
documentación del software
2. Agregar los botones de la interfaz
a. Un botón que active la cámara para tomar
una foto
b. Un botón para seleccionar una imagen desde
el directorio local
c. Un botón para procesar la imagen
seleccionada
d. Un botón para mostrar la documentación
Tomar una foto con la cámara del Raspberry Pi y
guardarla en formato JPEG
1. Indicar la dirección del fichero destino
2. Definir el formato JPEG para la imagen
capturada
3. Capturar una imagen
4. Guardar la imagen en el fichero destino
Subir imagenes en formato JPEG o PNG ya guardadas
en el directorio local
1. Indicar la dirección del fichero destino
2. Comprobar que el formato de la imagen sea
JPEG o PNG
3. Cargar la imagen a procesar

21. Listado de especificación de requerimientos
Identificar la tonalidad y brillo de los colores de los
objetos localizados
1. Transformar el modelo RGB a un modelo
de color orientado a la percepción visual
2. Revisar los valores cromáticos de los
pixeles de acuerdo al modelo del color
elegido
3. Determinar a qué tonalidad corresponden
los valores y que brillo posee tal color
Localizar los objetos dentro de la imagen
1. Particionar la imagen en múltiples
segmentos que correspondan a los
objetos
2. Delimitar los bordes de cada objeto por
individual
Determinar si el color identificado forma parte de los
colores confundidos en la deuteranomalía
3. Comparar el color de los objetos con el
conjunto de colores confundidos
4. Arrojar un resultado que establezca los
objetos a etiquetar

22. Listado de especificación de requerimientos
Guardar la imagen devuelta como respuesta
1. Indicar la dirección del fichero destino
2. Guardar la imagen en el fichero destino
Agregar una opción de ayuda para que el usuario
conozca la información del software
1. Incorporar una función que llame a la
ventana con la documentación
Devolver como respuesta la misma imagen procesada
pero con los colores ya identificados en etiquetas con
sus respectivos nombres y adjetivos
1. Crear las etiquetas que conlleven la
información cromática de los objetos
2. Localizar la correspondencia entre los
diferentes objetos y sus respectivas
etiquetas
3. Colocar las etiquetas sobre los objetos
que ya fueron determinados para tal
acción

23. Prototipo
➔ Prototipo posiblemente
desechable
➔ Apariencia y percepción
genérica de la interfaz gráfica
de usuario
➔ Parcial y flexible para ser
complementada con otras
vistas
Ventana principal de la interfaz gráfica

24. Revisión de los requerimientos
➔ Verificar trazabilidad entre los
documentos de requerimientos:
◆ Definición de requerimientos
◆ Especificación de requerimientos
➔ Evaluar ciertas variables como:
◆ Número de requerimientos
◆ Cantidad de cambios introducidos
➔ Medir cuantitativamente la calidad del
software:
◆ Rapidez, Fiabilidad, entre otros.
➔ Diagnosticar el estado de los
requerimientos mediante una encuesta
para diseñadores y verificadores
Medición de requerimientos
Etapa IV: Validación y verificación

25. Fase III: La Construcción
Durante la fase de construcción el
sistema es desarrollado y probado en el
ambiente de desarrollo. La finalidad de esta
fase es construir un software funcional en una
base regular e incremental, la cual cumpla
con las necesidades de prioridad más alta de
los involucrados de su proyecto.
En esta etapa se inicia el desarrollo del
software, una vez se tengan bien
especificados los requerimientos del mismo.
Desarrollo de las primeras ventanas de la interfaz
gráfica de usuario

26. Fase III: La Construcción
Del mismo modo, en esta etapa se
realizará la adaptación del espacio de
trabajo para realizar pruebas de ejecución
con las herramientas y tecnologías
seleccionadas. Esto con la finalidad de poder
analizar los métodos y técnicas existentes en
la librería OpenCV que se encuentren
orientados a detectar los colores de un
objeto en una imagen digital.
Así como también, se iniciará con el
desarrollo de los diferentes módulos del
software para la detección de colores de
un objeto en una imagen digital, a través
de la implementación de los algoritmos
correspondientes, los cuales se
complementarán entre sí para cumplir
con cada uno de los requerimientos
establecidos.

27. Fase IV: La Transición
Ya en la cuarta fase de la
metodología AUP, el software se lleva a
los espacios de calidad donde es
sometido a las pruebas de validación y
aceptación, con la finalidad de verificar la
funcionalidad del software antes de ser
desplegado en el ambiente de producción.
El dispositivo Raspberry Pi versión 3 modelo B
será el equipo de producción

28. Fase IV: La Transición En relación a lo anteriormente
expuesto, se establece que en esta fase sean
aplicadas todas aquellas pruebas a nivel
técnico y funcional, entiéndase por estas las
pruebas de caja blanca y caja negra para
buscar algún comportamiento no adecuado
y poder detectar posibles errores no
previstos. Y de esta manera, de ser posible,
realizar las correcciones respectivas,
además de verificar los algoritmos
implementados para la detección de colores
de objetos en una imagen digitalSistema operativo Raspbian donde se
implementará el software

29. A modo de resumen de la
metodología aplicada, se muestra
la siguiente gráfica en donde se
representan cada una de las fases
explicadas anteriormente.
La gráfica muestra la
cantidad de esfuerzo requerido
en las actividades de cada una de
las fases
Como se puede observar,
en cada fase se relacionan todas
las actividades, pero dependiendo
de la fase el esfuerzo dedicado a
una actividad en específico.

30. Factores de calidad
Corrección
Es el grado en el que un programa
satisface sus especificaciones y en el que
cumple con los objetivos de la misión del
cliente. En base a esto, es importante resaltar
que es necesario cumplir con las
especificaciones establecidas para el proyecto,
ya que sin estas el software no brindaría una
utilidad.
Por ejemplo, si no se logra alcanzar un
alto grado de precisión al reconocer los colores
de los objetos en una imagen digital, no se
podrá despejar la confusión de los colores que
poseen las personas con deuteranomalía.

31. Factores de calidad
Eficiencia
Es el grado en el que el software emplea
óptimamente los recursos del sistema, según
lo indican los subatributos siguientes:
comportamiento del tiempo y de los recursos.
Ejemplo de esto es la elección de Python
como lenguaje de programación adecuado
para el Raspberry Pi, debido al problema de
consumo de memoria ram que posee un
lenguaje como MATLAB, en referencia a las
librerías de procesamiento de imágenes
digitales.
Facilidad de uso
Es el esfuerzo que se requiere para
aprender, operar, preparar las entradas e
interpretar las salidas de un programa. Dicho esto,
a nivel de interfaz gráfica solamente el usuario
dispondrá de dos funcionalidades elementales, las
cuales son tomar una foto y cargar una imagen, de
tal forma que sean pocos los pasos para procesar
tal cosa.
Para respaldar aún más lo anterior, el
usuario contará con un botón de ayuda donde se
explique brevemente el uso del software.

32. Factores de calidad
Facilidad de prueba
Se refiere al esfuerzo que se requiere
para probar un programa a fin de garantizar
que realiza la función que se pretende.
Este factor tiene lugar en el proyecto,
debido a que se llevarán a cabo tanto pruebas
de ejecución para el análisis de métodos y
técnicas orientadas a detectar los colores de
un objeto en una imagen digital, como para las
pruebas de caja blanca y caja negra para la
verificación del correcto funcionamiento del
software.
Portabilidad
Es el esfuerzo que se necesita para
transferir el programa de un ambiente de
sistema de hardware o software a otro.
A partir de esto, gracias a que las
tecnologías que se usarán para el desarrollo
del software son multiplataformas, la
portabilidad del mismo está garantizada a
todos aquellos sistemas operativos que
permitan el uso de la librería PyGTK, como es
el caso de Windows y Linux.

33. Factores de calidad
Reusabilidad
Está relacionado al grado en el que un
programa (o partes de uno) pueden volverse a
utilizar en otras aplicaciones.
El sistema a desarrollar se puede dividir
en dos partes independientes: la interfaz
gráfica de usuario y el algoritmo de
procesamiento de imágenes digitales. En
consecuencia, cualquier otra aplicación puede
disponer de los beneficios que brindan estas
partes por separado.
Un ejemplo de esto es el desarrollo de
una aplicación similar a esta pero que esté
orientada a uno, varios o todos los tipos de
daltonismo, haciendo una modificación al
conjunto de colores a reconocer, incluyendo o
excluyendo uno o más de ellos.

34. Referencias Bibliográficas
● Pressman, R. (2010). Ingeniería del Software. Un enfoque práctico (7a ed). México, D.F.: Editorial
McGraw-Hill
● Ambler, S. (2005). Agile Unified Process. Proceso Ágil Unificado. Extraído desde:
http://www.ambysoft.com/unifiedprocess/agileUP.html
● Seymour, C. (2012). HOWTO: Configure Your Raspberry Pi With VNC Without Ever Connecting
It To A Keyboard & Monitor. Extraído desde:
https://lildude.co.uk/howto-configure-raspberry-pi-with-vnc-without-ever-connecting-keyboard-
monitor
● Industrial Shields (s.f.). Raspberry pi 3 Model B. Extraído desde:
https://www.industrialshields.com/es/shop/raspberry-pi-3-model-b/
● USERS.CODE (2008). LA BIBLIA DEL PROGRAMADOR IMPLEMENTACIÓN Y DEBUGGING.
Extraido desde: https://ingsw.pbworks.com/f/Ciclo+de+Vida+del+Software.pdf

35. Referencias Bibliográficas
● AulaFacil (2009). Apuntes de Teoría del Color. Extraído desde:
http://www.aulafacil.com/cursos/l13908/informatica/diseno-grafico-cad/gimp-2-6-10/apuntes-d
e-teoria-del-color
● Gavin, L. (2017). 12 Photos That Show How People With Color Blindness See The World.
Extraído desde:
https://www.providr.com/how-people-with-color-blindness-see-the-world/?f=one
● Stackoverflow (2015). Image (color?) segmentation with opencv C++. Extraído desde:
https://stackoverflow.com/questions/30303151/image-color-segmentation-with-opencv-c
● Gil, G. (2002). Herramienta para implementar lel y escenarios (TILS). Extraído desde:
http://postgrado.info.unlp.edu.ar/Carreras/Magisters/Ingenieria_de_Software/Tesis/Gil_Gustavo.
pdf