iTrust
1.0.0
Itrust es un sistema web médico y una base de datos que yo (Wolfski2) modificé y extendí con otros siete en un equipo como proyecto de curso. Cuenta con pruebas integrales de unidades y selenio con ~ 90% de cobertura de código.
Los archivos marcados con inicialización de mensajes de confirmación se incluyeron al comienzo del proyecto y nuestro equipo no cambió.
El desarrollo progresó por completo de acuerdo con un cronograma y fue especificado por casos de uso. Desarrollamos en parejas y practicamos una metodología de programación extrema. Nuestra línea de tiempo de desarrollo se dividió en tres iteraciones. Cada iteración en bicicleta a través de tres roles de liderazgo del líder de desarrollo, líder de control de calidad y líder de planificación. Nos dividimos en dos subteames de cuatro que a su vez se dividen en dos pares.
En las dos primeras iteraciones, nuestra tarea era implementar casos de uso asignados, mientras que en la tercera iteración creamos e implementamos nuestra propia UC.
En iteración 1 trabajé como par con SAM en UC41 SendReminders en Branch UC41_1. Creamos sendreminders.jsp, sendreminderaction.java y el método getupcomingappts en apptdao.java para consultar y devolver una lista de las próximas citas dentro de un número determinado de días. La convención estándar se siguió donde el JSP determina si la entrada está en formato correcto, y si es así, llama a la clase de acción, lo que a su vez llama al DAO para consultar el DB. Un segundo par (Jordi y Aidan) trabajó en la parte restante de la caja de recordatorios de UC41. Nos conocimos como grupo para revisar y fusionar nuestro código en UC41, y solo después de que UC41 se realizó por completo, lo fusionamos en Master con el resto del equipo.
WebRoot/auth/admin/sendReminders.jsp (+)src/edu/ncsu/csc/itrust/action/SendReminderAction.java (+)src/edu/ncsu/csc/itrust/dao/mysql/ApptDAO.java (*)test/edu/ncsu/csc/itrust/unit/action/SendReminderActionTest.java (+)test/edu/ncsu/csc/itrust/unit/dao/appointment/ApptDAOTest.java (*)test/edu/ncsu/csc/itrust/selenium/SendReminderTest.java (+) En iteración 2 trabajé como par con Sean en UC14 Solicitud de biosurveilance. Nuestro par trabajó en requestbiosurveIlKeAction.java y algoritmos de detección epidémica utilizando consultas de diagnóstico.
mientras que un segundo par (Nicholas y Xiaorui) creó la UI en requestbiosurveillance.jsp. Esta vez seguimos un mejor procedimiento abriendo una solicitud de fusión de nuestra rama UC14_1 en UC14. Otros miembros del equipo publicaron una revisión, y solucionamos problemas menores antes de fusionarse. Este proceso se repitió con una solicitud de fusión de UC14 al maestro. También revisé y comenté sobre otras solicitudes de fusión.
Arreglé el olor del tercer código de la iteración 1, y también fue el líder de garantía de calidad para la iteración 2. Verifiqué rutinariamente mi par y cualquier otra cobertura de código de iteración totalmente comprometida para garantizar que nuestras clases tuvieran al menos 80% de cobertura. Arreglé la prueba de otro par que tenía una cobertura demasiado baja en AddperregisteredPatientTest.java en Commit 6E881BDA. Antes de la demostración, atrapé un error crítico en requestbiosurveillance.jsp y agregué un parámetro a main () en testdatagenerator.java para cargar datos epidémicos en el DB. Si no se trata, ambos problemas habrían evitado que UC14 pudiera demostrarse.
src/edu/ncsu/csc/itrust/action/RequestBiosurveillanceAction.java (+)WebRoot/auth/hcp/requestBiosurveillance.jsp (*)test/edu/ncsu/csc/itrust/unit/action/RequestBiosurveillanceActionTest.java (+)test/edu/ncsu/csc/itrust/unit/dao/patient/AddPreRegisteredPatientTest.java (*)test/edu/ncsu/csc/itrust/unit/datagenerators/TestDataGenerator.java (*) En iteración 3 trabajé como par en UCOWN_2 HeatMap en la rama T4_OWN_2. Creamos ViewweeklySchedule.jsp y WeeklyScheduleaction.java por mostrar un mapa de calor de la cantidad de citas en una semana dada frente a la hora del día, con un tono más oscuro de rojo que indica más citas en una hora dada en un día. No pudimos encontrar una plantilla de mapa de calor satisfactoria en los gráficos de Google ni nada similar, por lo que creamos la nuestra usando una mesa JSP y un algoritmo que encuentra todas las citas en una semana determinada, las clasifica de día y hora en el día en una matriz 2D, y luego asigna esa matriz en una matriz de color de calor 2D para utilizar en la mesa de JSP. Hicimos una solicitud de fusión de T4_OWN_2 directamente en Master, porque esencialmente dividimos UCOWN en dos casos de uso completamente independientes. Se fusionó después de la revisión y la fijación menor. Nuevamente revisé y comenté sobre otras solicitudes de fusión con mi socio.
Aunque ya no era líder de garantía de calidad en iteración 3, todavía presté mucha atención a los resultados de las pruebas de todo el proyecto Itrust, y se corrigió un error UC92 en addperregisteredPatientTest.java y testdatagenerator.java que estaba impediendo que otras pruebas independientes pasaban debido a la inserción accidental de uno demasiados pacientes en el DB.
WebRoot/auth/admin/viewWeeklySchedule.jsp (+)src/edu/ncsu/csc/itrust/action/WeeklyScheduleAction.java (+)test/edu/ncsu/csc/itrust/unit/action/WeeklyScheduleActionTest.java (+)test/edu/ncsu/csc/itrust/unit/dao/patient/AddPreRegisteredPatientTest.java (*)test/edu/ncsu/csc/itrust/unit/datagenerators/TestDataGenerator.java (*)test/edu/ncsu/csc/itrust/selenium/viewWeeklyScheduleTest.java (+)
