iTrust
1.0.0
A ITRUST é um sistema da Web médico e um banco de dados que eu (Wolfski2) modificou e estendido com sete outros em uma equipe como um projeto de curso. Possui testes abrangentes de unidade e selênio com ~ 90% de cobertura de código.
Os arquivos marcados com a inicialização da mensagem de confirmação foram incluídos no início do projeto e permaneceram inalterados por nossa equipe.
O desenvolvimento progrediu inteiramente de acordo com um cronograma e foi especificado por casos de uso. Desenvolvemos em pares e praticamos a metodologia de programação extrema. Nossa linha do tempo de desenvolvimento foi dividida em três iterações. Toda iteração que percorremos três papéis de liderança de líder de desenvolvimento, líder de controle de qualidade e líder de planejamento. Dividimos em duas subtamas de quatro que, por sua vez, se dividem em dois pares.
Nas duas primeiras iterações, nossa tarefa foi implementar casos de uso atribuídos, enquanto na terceira iteração criamos e implementamos nossos próprios UCs.
Na iteração 1, trabalhei como par com SAM no UC41 SendreMinders na filial UC41_1. Criamos o sendReminders.jsp, sendReminderAction.java e o método GetupingAppts em apptdao.java para consultar e retornar uma lista dos próximos compromissos dentro de um determinado número de dias. A convenção padrão foi seguida onde o JSP determina se a entrada está no formato correto e, se assim, chama a classe de ação, que por sua vez chama o DAO para consultar o banco de dados. Um segundo par (Jordi e Aidan) trabalhou na parte restante da caixa de saída de lembretes UC41. Nós nos conhecemos como um grupo para revisar e mesclar nosso código no UC41, e somente depois que o UC41 foi feito totalmente, nós o mesclamos no mestre com o resto da equipe.
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.javatest/edu/ncsu/csc/itrust/unit/dao/appointment/ApptDAOTest.javatest/edu/ncsu/csc/itrust/selenium/SendReminderTest.java Na iteração 2, trabalhei como par com Sean no UC14 solicitar biossurveilância. Nosso par trabalhou no requestbiosurveillanceaction.java e algoritmos de detecção epidêmica usando consultas diagnósticasDAO,
Enquanto um segundo par (Nicholas e Xiaorui) criou a interface do usuário no requestbiosurveillance.jsp. Desta vez, seguimos um procedimento melhor, abrindo uma solicitação de mesclagem de nossa filial UC14_1 no UC14. Outros membros da equipe publicaram uma revisão e corrigimos pequenos problemas antes de se fundir. Esse processo foi repetido com uma solicitação de mesclagem da UC14 no mestre. Também revisei e comentei outras solicitações de mesclagem.
Corrigi o 3º cheiro de código da iteração 1 e também fui o líder de garantia de qualidade para a iteração 2. Eu rotineiramente verifiquei os meus pares e qualquer outra cobertura de código de iteração 2 totalmente comprometida para garantir que nossas classes tivessem pelo menos 80% de cobertura. Corrigi o teste de outro par que teve uma cobertura muito baixa no addPreregisterEdPatientTest.java no commit 6e881bda. Antes da demonstração, peguei um bug crítico no requestbiossurveillance.jsp e adicionei um parâmetro para main () no testDataGenerator.java para carregar dados epidêmicos no banco de dados. Se não fossem tratados, ambos os problemas teriam impedido que o UC14 pudesse demonstrar uma demonstração.
src/edu/ncsu/csc/itrust/action/RequestBiosurveillanceAction.java (+)WebRoot/auth/hcp/requestBiosurveillance.jsp (*)test/edu/ncsu/csc/itrust/unit/action/RequestBiosurveillanceActionTest.javatest/edu/ncsu/csc/itrust/unit/dao/patient/AddPreRegisteredPatientTest.javatest/edu/ncsu/csc/itrust/unit/datagenerators/TestDataGenerator.java Na iteração 3, trabalhei como um par no Ucown_2 Heatmap na filial T4_OWN_2. Criamos o ViewWeeklySchedule.jsp e WeeklyScheduleAction.java por exibir um mapa de calor de número de compromissos em uma determinada semana vs. hora do dia, com um tom mais escuro de vermelho indicando mais compromissos em uma determinada hora em um dia. Não conseguimos encontrar um modelo de mapa de calor satisfatório nos gráficos do Google ou qualquer coisa semelhante, por isso criamos o nosso usando uma tabela JSP e um algoritmo que encontra todos os compromissos em uma determinada semana, classifica -os por dia e por hora no dia em uma matriz 2D e depois mapeia a matriz de JASP 2D para a tabela JSP. Fizemos uma solicitação de mesclagem de T4_OWN_2 diretamente no Master, porque dividimos essencialmente em dois casos de uso completamente independentes. Foi mesclado após a revisão e a conservação menor. Mais uma vez, revisei e comentei outras solicitações de mesclagem com meu parceiro.
Embora eu não fosse mais líder de garantia de qualidade na iteração 3, ainda prestei muita atenção aos resultados dos testes de todo o projeto da ITRUST e corri um bug uc92 no addpreergisterDisteredPatienttest.java e testdatagenerator.java que estava impedindo que outros testes independentes passassem devido à inserção acidental de muitos pacientes em Pacientes para o DB.
WebRoot/auth/admin/viewWeeklySchedule.jsp (+)src/edu/ncsu/csc/itrust/action/WeeklyScheduleAction.java (+)test/edu/ncsu/csc/itrust/unit/action/WeeklyScheduleActionTest.javatest/edu/ncsu/csc/itrust/unit/dao/patient/AddPreRegisteredPatientTest.javatest/edu/ncsu/csc/itrust/unit/datagenerators/TestDataGenerator.javatest/edu/ncsu/csc/itrust/selenium/viewWeeklyScheduleTest.java (+)
