Resultados y notas del disenio y la construccion de caracteristicas

Resultados y notas del diseño y la construcción de características Yamit
1ª. Desplegar información de estándares:
La planeación y desarrollo de este conjunto de características fue bastante enriquecedor, dado
que se trabajo con herramientas bastantes nuevas y novedosas que aportaron para el que el
desarrollo fuera bastante sencillo de realizar y muy eficaz a la hora de cumplir con el objetivo
planteado (realizar búsquedas predictivas en una base de datos de más de tres mil registros en un
dispositivo móvil).
Al momento de realizar pruebas de interfaz, se encontraron inconvenientes con el estándar CUPS,
por algunos caracteres especiales usados en la descripción, para solucionarlo se hizo una
supresión de dichos caracteres en el documento usado para la precarga de los datos, también se
presentaros inconvenientes menores con el uso de las mayúsculas y el texto predictivo de algunos
celulares, la solución fue aplicar el método toLowerCase() de la clase String, al momento de
indexar y al momento de buscar.
Los resultados de los demás casos de pruebas fueron bastante óptimos y no presentaron
inconvenientes mayores.
11. gestionar consulta general
Diseñar este conjunto de característica fue un proceso de especial cuidado pues es una de las
características principales del sistema y en ella se apoyan gran parte de los demás procesos
realizados por el mismo. Dado que era un conjunto de características bastante amplio y
complicado de comunicar entre sí, la planeación excedió en medio día el tiempo estimado en el
cronograma.
Ya en la fase del desarrollo el retraso en los tiempos planteados fue mucho más notable, puesto
que debió tenerse bastante en cuenta el ciclo de vida de los objetos usados para la consulta
general y la metodología no proporciona mecanismos tales como los diagramas de objetos o de
estados para llevar este control. También resulto bastante agotador el desarrollo de toda la
interfaz grafica, puesto que este es un proceso “repetitivo y engorroso” pero no por ello poco
importante.
Al término de esta iteración se contemplo un consumo de tiempo del doble con respecto al
tiempo estimado en el cronograma (5 días).
12. solicitar servicios
Comparando la planeación del conjunto de características para la solicitud de servicios por parte
del médico en el momento de la consulta con la planeación de la gestión de la consulta general, la
primera resulto bastante sencilla en su diseño y plantea un modelo de fácil re uso con respecto a
los diferentes tipos de servicios involucrados, cabe resaltar que dicha planeación fue realizada en
la mitad del tiempo presupuestado en el cronograma (medio día).
Sin embargo durante la fase de implementación se presentaron algunos inconvenientes con el
desarrollo de la petición de formulas medicas, pues esta característica debía integrase con la
persistencia del estándar POS, y debería manejar una única fórmula por paciente atendido, así
pues se necesito desarrollar una estructura de datos que contuviese todos los medicamentos
agregados por el médico, y permitiera la modificación y eliminación de los mismos en cualquier
instante de tiempo antes del envío al servidor. Esto trajo consigo un retraso en el tiempo del
desarrollo excediendo en un día el tiempo planteado en el cronograma.
Durante este desarrollo se presentaron inconvenientes al momento de eliminar medicamentos
puesto que la estructura de datos para el manejo de medicamentos, y el listado renderizado de los
mismos en la interfaz grafica eran completamente independientes y fue necesario realizar una
búsqueda secuencial para asociar cada uno de los pares de objetos.
13. gestión de eventos
El diseño y la planeación de este conjunto de características se presento como un gran reto dentro
del marco que abarca en el sistema, pues si bien es claro que no es el principal rasgo de la
aplicación si es uno de los más llamativos, y de los que mayor trabajo requerían, pues además de
tener que brindar una solución optima, intuitiva y rápida, a la atención de procedimientos y
evaluación triage en situaciones de emergencia, también debería permitir al auxiliar medico tomar
fotografías, y adjuntar audio en los procedimientos realizados.
La planeación involucro dos fases, en la primera se realizo una investigación sobre el manejo de
contenido multimedia con j2me (MMAPI), en donde el diseñador y programador delimitaron y se
formaron una idea global del entorno que se podría crear, y la segunda fase involucro el diseño y
de las diferentes tipos de procedimientos brindados en el sistema (evento medico, y evaluación
triage).
La implementación fue llevada a cabo durante los tiempos estimados, y fue bastante óptimo el
resultado, sin embargo una semana después de la implementación de este conjunto de
características se encontró un bug mayor en la sección de grabación de audio, luego de pausar y
reanudar repetidamente la grabación sobre dispositivos nokia serie 40, los teléfonos generan un
volcado de memoria haciendo que el celular se reinicie. El tratamiento de este bug se trato por
dos días más, sin lograr corregirlo, se opto por continuar con el resto del desarrollo y restringir la
gama de celulares en los que la aplicación funcionara (exclusión de dispositivos nokia serie 40). A
la fecha de redacción de este documento, no ha sido posible corregir el bug.
14. Crear copia de seguridad en el móvil
Al diseñar este conjunto de características, en principio se definió una solución basada en RMS, sin
embargo se prestaba para dar gran complejidad al desarrollo, y hacer menos robusto el código,
pues había que “mapear” cada uno de los objetos involucrados en una consulta general, en un
procedimiento, y en los servicios, a gigantescos arrays de bytes. La solución fue implementar un
framework de almacenamiento de objetos en RMS llamado Floggyi, este framework es de origen
brasilero es open source, y vio la luz el 15 de junio del 2009, y su característica principal es la de
permitir el almacenamiento de objetos completos en almacenes RMS.
Este framework permitió realizar un diseño mucho mas pulido y entendible y facilito en gran
medida la implementación de las características, sin embargo se presento un atraso de 1 día en las
fechas propuestas, dado que el desarrollador debió familiarizarse con la herramienta.
15. sincronizar información guardada
La planeación y el desarrollo de este conjunto de características no presento mayor inconveniente,
puesto que solo represento hacer una integración de partes de dos módulos ya desarrollados, se
debía revisar en los almacenes de objetos si existía algún tipo de información pendiente por enviar
y de ser así, debería llamarse a los métodos de conexión para cada tipo de objeto y realizar el
envío. El punto más crítico fue la duración del envío de grandes cantidades de datos. Sin embargo
no sobrepaso los límites establecidos en el diseño de pruebas.
i
http://floggy.sourceforge.net/