iTrust
1.0.0
ITrust ist ein medizinisches Websystem und eine Datenbank, die I (Wolfski2) als Kursprojekt mit sieben anderen in einem Team verändert und erweitert hat. Es verfügt über umfassende Einheiten- und Selenium -Tests mit ~ 90% Codeabdeckung.
Zu Beginn des Projekts wurden Dateien mit der Initialisierung der Commit -Nachrichten aufgenommen und von unserem Team unverändert.
Die Entwicklung hat sich vollständig nach einem Zeitplan fortgesetzt und wurde durch Anwendungsfälle angegeben. Wir haben paarweise entwickelt und extreme Programmiermethoden praktiziert. Unsere Entwicklungszeitleiste wurde in drei Iterationen aufgeteilt. Jede Iteration, die wir durch drei Führungsrollen des Entwicklungsleiters, des QA -Führers und des Planungsleiters durchführten. Wir haben uns in zwei Subtometer von vier Turns aufgeteilt, die sich wiederum in zwei Paare aufteilten.
In den ersten beiden Iterationen war unsere Aufgabe, zugewiesene Anwendungsfälle zu implementieren, während wir in der dritten Iteration unsere eigenen UCs erstellt und implementiert haben.
In Iteration 1 habe ich als Paar mit SAM auf UC41 SendReminders in Zweig uc41_1 gearbeitet. Wir haben sendReminders.jsp, sendReminderaction.java und die Methode zur GetupcomingAPPTS in apptdao.java erstellt, um innerhalb einer bestimmten Anzahl von Tagen eine Liste der bevorstehenden Termine abzufragen und zurückzugeben. Die Standardkonvention wurde befolgt, wenn der JSP feststellt, ob die Eingabe in korrektem Format ist, und wenn dies die Aktionsklasse aufruft, was wiederum den DAO aufruft, um die DB abzufragen. Ein zweites Paar (Jordi und Aidan) arbeitete am verbleibenden Teil von UC41 -Erinnerungs -Outbox. Wir haben uns als Gruppe getroffen, um unseren Code in UC41 zu überprüfen und zusammenzuführen, und erst nachdem UC41 vollständig erledigt war, haben wir ihn mit dem Rest des Teams zum Master zusammengeführt.
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 (+) In Iteration 2 arbeitete ich als Paar mit Sean auf UC14 an, um Biosurveillance zu beantragen. Unser Paar arbeitete an RequestbiosurveillanceAction.java und epidemische Erkennungsalgorithmen unter Verwendung von Diagnosendao -Abfragen.
während ein zweites Paar (Nicholas und Xiaorui) die Benutzeroberfläche in RequestBiosurveill.jsp. Diesmal befolgten wir ein besseres Verfahren, indem wir eine Merge -Anfrage von unserem Zweig UC14_1 in UC14 eröffnet haben. Andere Mitglieder des Teams haben eine Bewertung veröffentlicht, und wir haben vor dem Zusammenführen kleinere Probleme behoben. Dieser Vorgang wurde mit einer Merge -Anfrage von UC14 in den Master wiederholt. Ich habe auch andere Zusammenführungsanfragen überprüft und kommentiert.
Ich habe den 3. Code -Geruch von Iteration 1 behoben und war auch der Qualitätssicherungsführer für Iteration 2. Ich habe routinemäßig die Codeabdeckung meines Paares und jede andere vollständig engagierte Iteration 2 -Code -Deckung überprüft, um sicherzustellen, dass unsere Klassen mindestens 80% abdecken. Ich habe den Test eines anderen Paares mit einer zu niedrigen Abdeckung in addPreregisteredPatientest.java in Commit 6E881BDA behoben. Vor der Demo habe ich einen kritischen Fehler in RequestBiosurveillance.jsp aufgenommen und main () in testDatagenerator.java einen Parameter hinzugefügt, um epidemische Daten in die DB zu laden. Bei unbehandelten Problemen hätten UC14 verhindert, dass sie in der Lage sind, Demo zu erstellen.
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 (*) In Iteration 3 habe ich als Paar für uCown_2 Heatmap in Zweig T4_Own_2 gearbeitet. Wir haben viewweeklySchedule.jsp und WeelyScheduleaction.java erstellt, um eine Hitzemahl von Termine in einer bestimmten Woche gegen Tagesstunde zu zeigen, wobei ein dunklerer Rotschatten von mehr Termine in einer bestimmten Stunde in einem Tag anzeigt. Wir konnten keine zufriedenstellende Heatmap -Vorlage in Google -Diagrammen oder ähnlichem finden. Daher haben wir unsere eigene mit einer JSP -Tabelle und einem Algorithmus erstellt, der alle Termine in einer bestimmten Woche findet, sie tagsüber und nach Stunde tagsüber in ein 2D -Array sortiert und dann in ein Array in ein 2D -Hitzemap -Farbarray, das in den JSP -Tabellen verwendet wurde, in die in der JSP -Tabelle verwendete Array karten. Wir haben eine Merge -Anfrage von T4_Own_2 direkt in den Master gestellt, da wir UCOWN im Wesentlichen in zwei völlig unabhängige Anwendungsfälle aufgeteilt haben. Es wurde nach Bewertung und geringfügiger Fixierung zusammengeführt. Wieder überprüfte und kommentierte ich andere Zusammenführungsanfragen mit meinem Partner.
Obwohl ich in Iteration 3 nicht mehr Qualitätssicherungsleiter war, achtete ich noch genau auf die Testergebnisse des gesamten Itrust -Projekts und fixierte einen UC92 -Fehler in AddPreeregisteredPatiententest.java und testDatagenerator.
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 (+)
