iTrust
1.0.0
ITRUst est un système Web médical et une base de données que I (Wolfski2) a modifié et étendu avec sept autres personnes en équipe en tant que projet de cours. Il propose des tests d'unité et de sélénium complets avec une couverture de code ~ 90%.
Les fichiers marqués par l'initialisation des messages de validation ont été inclus au début du projet et ont été inchangés par notre équipe.
Le développement a progressé entièrement selon un calendrier et a été spécifié par les cas d'utilisation. Nous avons développé par paires et pratiqué une méthodologie de programmation extrême. Notre calendrier de développement a été divisé en trois itérations. Chaque itération que nous avons parcouru trois rôles de leadership du leader du développement, du leader de l'AQ et du leader de la planification. Nous nous sommes divisés en deux sous-équipes de quatre qui à leur tour se sont divisées en deux paires.
Dans les deux premières itérations, notre tâche était de mettre en œuvre des cas d'utilisation assignés tandis que dans la troisième itération, nous avons créé et implémenté nos propres UC.
Dans l'itération 1, j'ai travaillé comme une paire avec SAM sur UC41 SendreMinders dans la branche UC41_1. Nous avons créé SendreDinders.jsp, SendrEminderAction.java et la méthode GuptOwncomingAppts dans apptdao.java pour interroger et retourner une liste des nominations à venir dans un nombre donné de jours. La convention standard a été suivie lorsque le JSP détermine si l'entrée est en format correct, et si oui, appelle la classe d'action, qui à son tour appelle le DAO pour interroger la DB. Une deuxième paire (Jordi et Aidan) a travaillé sur la partie restante de la boîte d'envoi des rappels UC41. Nous nous sommes rencontrés en groupe pour examiner et fusionner notre code dans UC41, et ce n'est qu'après UC41 entièrement terminé que nous l'avons fusionné avec le reste de l'équipe.
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 (+) Dans Itération 2, j'ai travaillé comme une paire avec Sean sur la biosurveillance de demande UC14. Notre paire a travaillé sur les algorithmes de détection de demande de demande
tandis qu'une deuxième paire (Nicholas et Xiaorui) a créé l'interface utilisateur dans requestbiosurveillance.jsp. Cette fois, nous avons suivi une meilleure procédure en ouvrant une demande de fusion de notre branche UC14_1 dans UC14. D'autres membres de l'équipe ont publié un examen, et nous avons résolu des problèmes mineurs avant la fusion. Ce processus a été répété avec une demande de fusion de UC14 dans Master. J'ai également examiné et commenté d'autres demandes de fusion.
J'ai corrigé l'odeur du 3e code de l'itération 1, et j'étais également le leader de l'assurance qualité pour l'itération 2. J'ai systématiquement vérifié la couverture du code de mon paire et de mon autre entièrement engagée pour m'assurer que nos cours avaient une couverture au moins 80%. J'ai corrigé le test d'une autre paire qui avait une couverture trop faible dans AddpregeRedPatientTest.java dans Commit 6E881BDA. Avant la démo, j'ai attrapé un bogue critique dans requestBiosurveIlance.jsp et ajouté un paramètre à main () dans TestDatagenerator.java pour charger des données épidémiques à la base de données. S'il n'est pas traité, les deux problèmes auraient empêché UC14 de pouvoir faire une démonstration.
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 (*) Dans Itération 3, j'ai travaillé comme une paire sur UCown_2 HeatMap dans Branch T4_OWN_2. Nous avons créé ViewweeklySchedule.jsp et WeeklyScheduleAction.java pour afficher une carte thermique de nombre de rendez-vous au cours d'une semaine donnée contre l'heure de la journée, avec une nuance de rouge plus sombre indiquant plus de nominations dans une heure donnée en une journée. Nous n'avons pas pu trouver un modèle de carte thermique satisfaisante sur les graphiques Google ou quelque chose de similaire, nous avons donc créé le nôtre en utilisant une table JSP et un algorithme qui trouve tous les rendez-vous dans une semaine donnée, les trie de jour et à l'heure dans la journée dans un tableau 2D, puis des cartes qui se sont en train de se produire dans un tableau de couleur 2D HEATMAP à utiliser dans le tableau JSP. Nous avons fait une demande de fusion de t4_own_2 directement dans Master, car nous avons essentiellement divisé UCown en deux cas d'utilisation complètement indépendants. Il a été fusionné après examen et fixation mineure. Encore une fois, j'ai examiné et commenté d'autres demandes de fusion avec mon partenaire.
Bien que je n'étais plus le leader de l'assurance de la qualité dans l'itération 3, j'ai toujours accordé une attention particulière aux résultats des tests de l'ensemble du projet ITRUST, et j'ai corrigé un bogue UC92 dans AdpreregisteredPatientTest.Java et TestDatagenerator.Java qui empêchait d'autres tests indépendants de passer en raison de l'insertion accidentelle d'un trop grand nombre de patients dans la 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 (+)
