iTrust
1.0.0
ItRust - это медицинская веб -система и база данных, которую я (Wolfski2) изменил и расширил с семью другими в команде в качестве курса. Он оснащена комплексными тестами на единицу и селене с охватом кода ~ 90%.
Файлы, помеченные инициализацией сообщений о коммите, были включены в начале проекта и не были изменены нашей командой.
Развитие полностью прогрессировало в соответствии с графиком и была указана с помощью вариантов использования. Мы разработали парами и практиковали методологию экстремального программирования. Наша график развития была разделена на три итерации. Каждая итерация, которую мы провели велосипеды с тремя руководящими ролями лидера по развитию, лидера QA и лидера планирования. Мы разделились на два подчинка из четырех, которые, в свою очередь, разделились на две пары.
В первых двух итерациях нашей задачей было реализация назначенных вариантов использования, в то время как в третьей итерации мы создали и реализовали нашу собственную UC.
В итерации 1 я работал в паре с SAM на UC41 SendReminders в филиале UC41_1. Мы создали SendReminders.jsp, SendReminderAction.java и метод GetupingComeAppts в apptdao.java, чтобы запросить и вернуть список предстоящих встреч в течение определенного количества дней. Стандартное соглашение было последовало, когда JSP определяет, находится ли ввод в правильном формате, и если это так вызывает класс действий, который, в свою очередь, вызывает DAO для запроса DB. Вторая пара (Джорди и Эйдан) работала над оставшейся частью Oc41 Opbober. Мы встретились как группа, чтобы просмотреть и объединить наш код в UC41, и только после того, как UC41 был полностью сделан, мы объединили его в Мастер с остальной частью команды.
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 (+) В итерации 2 я работал в паре с Шоном в UC14 запроса BioSurveillance. Наша пара работала над алгоритмами requestBioSurveillanceaction.java и эпидемии с использованием диагнозов -запросов,
В то время как вторая пара (Николас и Сяоруи) создали пользовательский интерфейс в requestbiosurveillance.jsp. На этот раз мы следовали лучшей процедуре, открыв запрос на слияние из нашего филиала UC14_1 в UC14. Другие члены команды опубликовали обзор, и мы исправили незначительные проблемы перед слиянием. Этот процесс был повторен с запросом на слияние от UC14 в Master. Я также просмотрел и прокомментировал другие запросы на слияние.
Я исправил 3 -й код запах кода с итерации 1, а также был лидером по обеспечению качества для итерации 2. Я обычно проверял свою пару и любые другие полностью совершенные итерационные покрытия 2, чтобы гарантировать, что наши занятия имеют охват не менее 80%. Я исправил тест другой пары, который имел слишком низкое покрытие в AddPrereGisteredPatientTest.java в Commit 6e881bda. Перед демонстрацией я поймал критическую ошибку в requestBioSurveillance.jsp и добавил параметр в main () в testDatagenerator.java для загрузки эпидемических данных в БД. В случае нелечения обе проблемы не позволили бы UC14 возможность продемонстрировать.
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 (*) В итерации 3 я работал в паре на тепловой карте UCown_2 в Branch T4_own_2. Мы создали ViewWeeklySchedule.jsp и WeeklyScheduleAction.java для демонстрации тепловой карты количества встреч в течение определенной недели против часа дня, с более темным оттенком красного, указывающего на большее количество назначений в течение определенного часа в день. Мы не смогли найти удовлетворительный шаблон тепловой карты в диаграммах Google или чего -либо подобного, поэтому мы создали нашу собственную таблицу JSP и алгоритм, который находит все встречи в определенной неделе, сортирует их днем и по часу дня в 2D -массив, а затем карты, которые массивы в массиве 2D -карты будут использованы в таблице JSP. Мы сделали запрос на слияние от T4_OWN_2 непосредственно в Master, потому что мы по существу разделили UCOWN на два совершенно независимого варианта использования. Это было объединено после обзора и незначительного исправления. Я снова просмотрел и прокомментировал другие запросы на слияние с моим партнером.
Хотя я больше не был лидером по обеспечению качества в Итерации 3, я все еще обращал пристальное внимание, чтобы испытать результаты всего проекта ITRUST, и исправил ошибку UC92 в addPrereGisteredPatientTest.java и TestDatagenerator. Java, который предотвращал прохождение других независимых тестов из -за случайной введения одного слишком многих пациентов в 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 (+)
