Relatório Final DanielaAmericadaSilva_04Jul

(1)

Projeto de

STAMPS

Projeto de Soluções Tecnológicas Aplicáveis a Mídias e Produtos em Saúde.

Instituto Tecnológico de Aeronáutica - ITA

Relatório Final

Time de Desenvolvimento:

PO: Rodrigo Santana (CE-229)

SM: Daniela América da Silva (CE-229)

TMs: Luckeciano Melo (CE-240), Samara Cardoso (CE-240),

Viktor Pugliese (CE-240 / CE-245), Felipe Tuyama (CE-245),

Fabio Kfouri (CE-245)

(2)

1. Introdução

1.1 Motivação

O Projeto de STAMPS 2017 refere-se ao desenvolvimento de um sistema integrado para organizações públicas e/ou privadas envolvidas com gestão de crises envolvendo eventos de saúde (por exemplo, epidemias).

O Projeto de STAMPS 2017 foi desenvolvido por 4 times focados em funcionalidades especificas, sendo o time 02 do qual participei, responsável pelo subsistema de médicos.

O Time TS02 tem por objetivo propor soluções tecnológicas aplicáveis a mídias e produtos em Saúde, para profissionais da saúde, no diagnóstico de doenças.

1.2 Contexto

Para organizações públicas e/ou privadas envolvidas com gestão de crises envolvendo eventos de saúde (por exemplo, epidemias) que necessitam gerenciar dados e informações para tomadas de decisões,o Projeto de STAMPS Acadêmico é um Sistema Computacional baseado em Big Data, Internet das Coisas e outras Tecnologias emergentes que agrega dados, integrando os atores deste cenário (Pacientes, Médicos, Hospitais e Fornecedores), para tomada de decisão.

Diferentemente de outros produtos existentes em Universidades, Institutos de Pesquisa, Agências Governamentais ou Empresas Públicas e/ou Privadas, este produto será desenvolvido e testado, em 17 semanas acadêmicas, utilizando-se metodologia ágil e suas boas práticas disponíveis no mercado em um cenário fictício de crise.

Imagem 1 – Estrutura Organizacional

1.3 Objetivo do Time Scrum

O subsistema de Médicos TS02 foi projetado para o desenvolvimento do Projeto de STAMPS Acadêmico, e seus segmentos, que necessitarão integrar dados para o controle epidemiológico, o TS02 é responsável pelo estudo de tecnologias e o desenvolvimento de soluções, envolvendo o segmento Médico.

Diferentemente dos outros times, o Time Scrum 02 importa-se em diagnosticar a enfermidade do paciente, através de Mídias Sociais e Consultas Médicas, utilizando-se de melhores práticas e tecnologias de ponta, com qualidade, confiabilidade, segurança e testabilidade, a fim de mapear potenciais alertas de surto e/ou epidemia.

(3)

1.4 Redução de Escopo

O TS#02 focou o desenvolvimento do produto nas User Stories referente a troca constante de mensagens com o STAMPSNet e através de mensagens recebidas de Pacientes (mídias sociais) e Médicos (consultas médicas), envia-se notificações para Hospitais, Fornecedores e Autoridades e no desenvolvimento de uma inteligência de Diagnóstico e envio de alertas para os subsistemas de Hospitais, Fornecedores e Autoridades.

O TS#02 utilizou três tipos de modelos para a inteligência de Diagnóstico: Index de Jaccard, Probabilistico e Incidencia para o alerta de epidemias.

O TS#02 focou no desenvolvimento de três tipos de alertas para notificar autoridades conforme resultados do modelo de Incidencia obedecendo as regras da Agência Nacional de Vigilância Sanitária de que Todo caso suspeito deve ser notificado imediatamente para as autoridades de saúde das Secretarias municipais, Estaduais e à Secretaria de Vigilância em Saúde.

 Green: Normal;

 Yellow: Estado de atenção/surto;  Red: Estado crítico de atenção/Epidemia;

1.5 Especificação de Requisitos

Participei de todas as meetings semanais como Scrum Master e como testadora, participando do planning poker e a definição das meta, e acompanhamento do desenvolvimento das US#s. E na preparação da apresentação, do relatório sintético e da planilha de testes. E participei das conversas com o time sobre a missão atribuída e a nossa participação no roteiro final.

Participei também da apresentação final no auditório Celso Renna no dia 30-Julho apresentando os tópicos: Introdução, Contextualização, Método Ágil e Missão Atribuída.

Acompanhei as discussões do time sobre como efetuar as integrações através do STAMPSNet com os demais times, a definição das mensagens e documentos canônicos, e o timeline para envio dos alertas de acordo com a missão atribuída.

1.1 Ordem de Apresentação do Relatório do Projeto Final da Disciplina

 Visão do Time

 Epidemias no Brasil (Números)  Arquitetura

 Modelos de Diagnósticos

 Inteligência para Diagnósticos – Geral e Ebola  Cáculo de Incidência – Epidemia

 Flows Mídia Social, Médicos, Encerramento da Crise e Paciente Shopping (Missão Atribuída)  Resultados

 Benefícios Adicionais  Contribuições TS#02

2. Desenvolvimento

(4)

Visão Projeto de STAMPS Acadêmico

Para organizações públicas e/ou privadas envolvidas com gestão de crises envolvendo eventos de saúde (por exemplo, epidemias)

que necessitam gerenciar dados e informações para tomadas de decisões,

o Projeto de STAMPS Acadêmico

é um Sistema Computacional baseado em Big Data, Internet das Coisas e outras Tecnologias emergentes que agrega dados, integrando os atores deste cenário (Pacientes, Médicos, Hospitais e Fornecedores), para tomada de decisão.

Diferentemente de outros produtos existentes em Universidades, Institutos de Pesquisa, Agências Governamentais ou Empresas Públicas e/ou Privadas,

este produto será desenvolvido e testado, em 17 semanas acadêmicas, utilizando-se metodologia ágil e suas boas práticas disponíveis no mercado em um cenário fictício de crise.

Visão Médicos TS02

Para o desenvolvimento do Projeto de STAMPS Acadêmico, e seus segmentos,

que necessitarão integrar dados para o controle epidemiológico,

o TS02

é responsável pelo estudo de tecnologias e o desenvolvimento de soluções, envolvendo o segmento Médico.

Diferentemente dos outros times, o Time Scrum 02 importa-se em diagnosticar a enfermidade do paciente, através de Mídias Sociais e Consultas Médicas, utilizando-se de melhores práticas e tecnologias de ponta, com qualidade, confiabilidade, segurança e testabilidade, a fim de mapear potenciais alertas de surto e/ou epidemia.

2.2 As User Stories efetivamente implementadas no meu TS02

2.2.1 Sprint 1

ID User Story

TS02-US03 COMO médico do Projeto de STAMPS, DESEJO ter o prontuário eletrônico com dados do paciente, data do atendimento e espaço para diagnóstico, prescrição, tratamento e evolução PARA descrever o atendimento ao paciente

TS02-US10 COMO médico do Projeto de STAMPS, DESEJO cadastrar doenças PARA um fórum de de discussão de diagnóstico com opiniões de outros especialistas da área de saúde

TS02-US13 [META] COMO médico do Projeto de STAMPS, DESEJO um cadastro de médicos PARA o controle de STAFF

TS02-US16 [META] COMO médico do Projeto de STAMPS, DESEJO um cadastro de paramédicos e especialistas PARA o controle do STAFF no atendimento de emergência e casos complexos.

(5)

2.2.2 Sprint 2

ID User Story

TS02-US27 COMO Médico do Projeto de STAMPS,

DESEJO receber lista de possíveis diagnósticos da enfermidade do paciente, PARA agilizar o tratamento e o tempo de atendimento.

TS02-US208 [META] DESEJO um oráculo (parâmetros e indicadores) PARA poder configurar de maneira automática o processo de triagem

TS02-US210 DESEJO um oráculo (documentos canônicos) PARA poder configurar as mensagens que serão enviadas 2.2.3 Sprint 3

ID User Story

TS02-US209 COMO Usuário do STAMPSNet,DESEJO implementar um processo modelo preditivo, PARA identificar possíveis alertas

TS02-US211 [META] COMO Usuário do STAMPSNet,DESEJO formatar mensagens de alerta PARA, reportar as devidas autoridades e segmentos

TS02-US10 COMO médico do Projeto de STAMPS, DESEJO cadastrar doenças PARA um fórum de de discussão de _{diagnóstico com opiniões de outros especialistas da área de saúde} 2.2.4 Arquitetura de Software TS02

Imagem 2 – Tecnologias Adotadas e STAMPSNet aplicado ao TS02 2.2.5 Como foram solucionados os principais desafios de integração entre Times

A estratégia de integração entre grupos de componentes de subsistemas ocorreu definindo outra arquitetura no topo desses subsistemas, chamada STAMPsNet. O STAMPsNet é um sistema inteligente que define a macro estratégia de integração entre as equipes que utilizam como etapas principais eventos enviados pelos subsistemas processados de acordo com as seguintes fases: detecção, rastreio, tratamento e resposta.

O STAMPSNet funciona de acordo com as seguintes etapas:

1. Detecção: obtém dados de doenças de midia social (por exemplo, twitter, google e facebook), prefeitura, hospitais e outros 2. Triagem: ele organizará esses dados usando um sistema inteligente, propiciando a localização dos eventos, identificando os

(6)

3. Tratamento: De acordo com as informações identificadas e organizadas na fase de triagem, ela irá processar os dados e enviar e alertar. Também tratará falso / alertas positivos antes de enviá-lo;

4. Resposta: De acordo com o evento, notificará a cada subsistema, PACIENTES, MÉDICOS, HOSPITAIS e

FORNECEDORES, o que deve ser feito, e. Locais de prevenção, críticas, o que fazer em caso de epidemias, o que os fornecedores devem fornecer para gerenciar as crises. Esta notificação também será enviada para autoridades como prefeitura e exército. Depois que a situação estiver sob controle, o alerta será fechado.

Imagem 3 – Estratégia de Integração STAMPSNet

2.3 Descrição dos Testes de Software

2.3.1 Materiais de referência tais como Diagramas, Códigos-fonte e Relatórios de Falhas, entre outros Artefatos necessários ao entendimento da sua colaboração individual no Projeto;

O projeto STAMPS foi desenvolvido usando a metodologia TDD (Test Development Driven), tendo os requisitos transformados em casos de teste e o desenvolvimento é feito levando em consideração as especificações dos casos de teste. E o produto foi validado contra esses casos de testes a cada semana de cada Sprint, através de um processo de desenvolvimento iterativo, onde os requisitos evoluem através da colaboração entre os membros da equipe de desenvolvimento, o proprietário do produto e as partes interessadas. A equipe é auto-organizada e determina os problemas com antecedência e diferente dos métodos convencionais quando o teste é realizado após a implementação, neste cenário o teste é feito durante a implementação.

BDD (Behavior Driven Development) foi implementado na Sprint 2 especificamente pela equipe TS04, usando a ferramenta Cucumber para automatizar testes relacionados ao comportamento da aplicação. Pela equipe TS02 o BDD foi utilizado na Sprint 2 para descrever os testes baseado no comportamento do sistema. Ele economizou tempo da equipe para investir em testes exploratórios.

Participei da realização dos testes e preparei as evidencias conforme descrito nos itens abaixo. 2.3.1.1 Sprint 1

Tabela de Decisao: https://drive.google.com/open?id=1kJWVcm6Eo_BZW1oAXGf4cMfAVJzLfXn43EammSbPsk0

Abaixo um exemplo de Tabela de Decisão para a US13 na Sprint 1. Os exemplos para as demais USs estão no Anexo A. Site Produtivo: http://stamps-medicos.herokuapp.com/

(7)

Imagem 4 – Exemplo de Tabela de Decisão US13 2.3.1.2 Sprint 2

Evidencias dos testes -> https://drive.google.com/open?id=1DvIh9dWhNYE7mSwNCzftB5g9FwokWtdiaA9KGmMESW8

Abaixo um exemplo do projeto de banco de dados utilizado para o cálculo de incidência máxima esperada na US208.

(8)

2.3.1.3 Sprint 3

Evidencias dos testes ->

https://drive.google.com/open?id=13kNWitOtURDhx6JjWR4g2pQJqHWdWfwf3J77d_pF0uQ

Abaixo um exemplo dos testes para o modelo preditivo de diagnósticos com o teste efetuado para o Ebola.

Imagem 6 – Exemplo de Testes da Inteligência de Diagnósticos 2.3.2 Um Plano de Teste para as USs em que estive envolvida

2.3.2.1 Sprint 1 Test Case Section

User Story User Story Acceptance Criteria Test Case Test Steps What To Expect Test Data Actual Result Status

TS02-US03

COMO medico do Projeto de STAMPS, DESEJO ter o prontuário eletrônico com dados do paciente, data do atendimento e espaço para diagnostico, preescrição, tratamento e evolução PARA descrever o atendimento ao paciente

Tela de cadastro de prontuário desenvolvida, testada e disponivel no GitHub, possibilitando também a futura integração com o cadastro de pacientes do TS01

Verificar se informacoes de prontuario estao disponiveis para cadastro e mantidas em um banco ou mockup

1-acessar site do prontuario 2- preencher dados do paciente, data, diagnostico,preescricao, tratamento e evolucao 3- salvar dados Dados do prontuario salvos em um mockup ou em uma database e visiveis para visualizacao

Telas disponíveis para a triagem e para a consulta do paciente anexando a triagem.

Teste Unitário efetuado pelo desenvolvedor. Deploy to código em

produção e teste de caixa preta da equipe de testes concluído. Detalhes

tab "US03"

concluido

TS02-US10

COMO médico do Projeto de STAMPS, DESEJO cadastrar doenças PARA um fórum de de discussão de diagnóstico com opiniões de outros especialistas da área de saúde

Tela de cadastro de doenças e forum desenvolvido, testado e disponivel no GitHub, utilizando dados de classificação internacional de doenças IDC 10

Verificar se cadastro de doenca esta disponivel, baseado no IDC e forum criado

1-acessar cadastro de doencas 2- selecionar alguma doenca baseado no IDC ou cadastrar uma 3 - salvar os dados 4- acessar o forum 5- publicar algum comentario

Doencas listadas e cadastradas. forum disponivel para leitura e publicacao

Tela disponivel para consulta de doenças do CID-10. Consulta funcionando apropriadamente com opção de selecionar dados do banco de dados.

tab "US10"

concluido

TS02-US13 [META] COMO medico do Projeto de STAMPS, DESEJO um cadastro de médicos PARA o controle de STAFF.

Tela de cadastro de médicos desenvolvida, testada e disponivel no GitHub, identificando a respectiva especialidade de acordo com a classificação internacional de doenças IDC10.

verificar se cadastro de medicos esta disponivel e que lista de doencas IDC tambem

1-acessar site de cadastro de medicos

2- preencher dados do medico 3- selecionar especialidade 4- salvar dados Dados do medico salvos em um mockup ou em uma database e visiveis para visualizacao

Tela disponivel para inserção, deleção e consulta e pronta para testes.

tab "US16"

concluido

TS02-US16

[META] COMO medico do Projeto de STAMPS, DESEJO um cadastro de paramédicos e especialistas PARA o controle do STAFF no atendimento de emergencia e casos complexos.

Tela de cadastro de médicos desenvolvida, testada e disponivel no GitHub, identificando se o profissional é paramédico e/ou especialista

verificar se opção de paramedico/especialista está disponivel

1-acessar site de cadastro de medicos

2- preencher dados do medico 3- selecionar especialidade 4- selecionar paramedico 5- salvar dados Dados do medico salvos em um mockup ou em uma database e visiveis para visualizacao

Tela disponivel para inserção, deleção e consulta e pronta para testes.

tab "US13"

concluido

US27 COMO médico do Projeto de STAMPS, DESEJO receber lista de possíveis diagnósticos da enfemidade do paciente,

PARA agilizar o tratamento e o tempo de atendimento.

"- Ferramenta de apoio ao diagnostico médico desenvolvida, testada e disponível no GitHub, possibilitando também a disponibilização de dados no barramento para serem consumidos pelo dashboard e pelos os outros times do projeto "

- ferramenta para apoio a decisão do médico desenvolvida e baseada no CID, apoiando o médico na identificação de suspeita ou confirmação de doença - disponibilizar os dados de decisão do médico no barramento

1- acessar a ferramenta de apoio a diagnostico médico

2- verificar a sugestão de doença do CID conforme sintomas

3- verificar se sugestão esclarece similaridade com sintomas de outras doenças Dados do diagnostico médico visiveis e disponibilizados no barramento Kafka fever,blood, headache,

cold varios tipos de doencas diferentes ok

US208 [META] DESEJO um oráculo (parâmetros e

indicadores) PARA poder configurar de maneira automática o processo de triagem

- Respectiva parametrização do Oraculo desenvolvida, testada e disponível no GitHub

Verificar se a parametrização do Oráculo permite cadastrar parametros para alertas: - evitar que um sintoma seja confundido com outra doença (e.g.o ebola pode ser confundido com uma gripe, com febre e dores de cabeça). - definir o periodo de análise de suspeita até a confirmação (e.g. para o ebola é necessário uma monitoração de até 3 semanas do paciente para confirmar a suspeita). - definir um parametro para alerta de surto de acordo com as regras de uma localização (e.g. no Congo com 9 casos já foi declarado surto). - definir um parametro para encerrar o alerta de epidemia/surto (e.g. para o Ebola A epidemia/surto só é declarada como encerrada se nenhum caso for detectado em 42 dias).

- utilizar também os critérios de gravidade do CID - localidade,

1- propiciar um Oraculo 2- propiciar identificar doenças com sintomas comuns

3- propiciar periodo de acompanhamento da doença até confirmação de caso 4- propiciar alerta de surto de acordo com as regras da localização 5- propiciar encerrar alerta de epidemia/surto

6- propiciar os critérios de alerta do CID (localidade, gravidade, velocidade de contágio, taxa de mortalidade e custo estimado de tratamento) 7- propiciar monitorar as pessoas em contato com pacientes suspeitos de doença letal.

8 - propiciar dados em Ingles

Dados do Oráculo identificados em um mockup ou em uma database e disponiveis para consumo no kafka

O Artefato foi criado com o exemplo de JSON a ser gerado e a

definição de cada campo, pra que serve e

que tipo de dado passar. O respectivo código python tambem

foi disponibilizado.

Validado a definição de cada campo, pra que serve e que tipo de dado utilizado como

parametro. Utilizou JSON.

OK

(9)

gravidade, velocidade de contágio (e.g. Para o Ebola A98.4 - Gravidade de 1 a 5; Velocidade de Contágio de 1 a 5; Taxa de mortalidade de 1 a 5; Custo esitmado de tratamento de 1 a 5)

- definir um parametro para que pessoas em contato com pacientes com suspeita de doença letal também sejam monitoradas. - dados cadastrados em Ingles e a ser utilizado uma tabela para tradução do portugues para ingles, para a pesquisa de palavras chaves da mídia social

US210 DESEJO um oráculo (documentos canônicos)

PARA poder configurar as mensagens que serão enviadas

- Dados canonicos para o barramento desenvolvido, testado e disponível no GitHub

Verificar se os dados canonicos permitem o envio das mensagens abaixo conforme tipos de alertas: - dados canonicos que indique doenças com sintomas semelhantes. (e.g.o ebola pode ser confundido com uma gripe, com febre e dores de cabeça).

- dados canonicos para o periodo de análise de suspeita até a confirmação (e.g. para o ebola é necessário uma monitoração de até 3 semanas do paciente para confirmar a suspeita). - dados canonicos para alerta de surto de acordo com as regras de uma localização (e.g. no Congo com 9 casos de Ebola já foi declarado surto).

- dados canonicos encerrar o alerta de epidemia/surto (e.g. para o Ebola A epidemia/surto só é declarada como encerrada se nenhum caso for detectado em 42 dias). - dados canonicos para alertas utilizando os critérios de gravidade do CID - localidade, gravidade, velocidade de contágio (e.g. Para o Ebola A98.4 - Gravidade de 1 a 5; Velocidade de Contágio de 1 a 5; Taxa de mortalidade de 1 a 5; Custo estimado de tratamento de 1 a 5) - definir canonicos para alerta sobre pessoas em contato com pacientes com suspeita de doença letal também sejam monitoradas. - dados canonicos utilizarão o Ingles como idioma

1- propiciar dados canonicos 2- propiciar dado canonico para doenças com sintomas comuns 3- propiciar dado canonico para periodo de acompanhamento da doença até confirmação de caso

4- propiciar dado canonico para alerta de surto de acordo com as regras da localização

5- propiciar canonico para encerrar alerta de epidemia/surto

6- propiciar dado canonico para os critérios de alerta do CID (localidade, gravidade, velocidade de contágio, taxa de mortalidade e custo estimado de tratamento)

7- propiciar dado canonico para monitorar as pessoas em contato com pacientes suspeitos de doença letal. 8 - propiciar dado canonico em Ingles

Dados canonicos para o Oráculo identificados em um mockup ou em uma database e disponiveis para consumo no kafka

O Artefato foi criado com o exemplo de JSON a ser gerado e a

definição de cada campo, pra que serve e

que tipo de dado passar. O respectivo código python tambem

foi disponibilizado.

Validado a definição de cada campo, pra que serve e que tipo de dado passar. Utilizou o

JSON.

OK

US209

COMO Usuário do STAMPSNet, DESEJO implementar um processo modelo preditivo,

PARA identificar possíveis alertas

- Ferramenta de apoio ao diagnostico médico desenvolvida, testada e disponível no GitHub, possibilitando também a disponibilização de dados no barramento para serem consumidos pelo dashboard e pelos os outros times do projeto

Verificar diagnosticos preditivos

1- acessar a ferramenta de apoio a diagnostico médico

2- verificar a sugestão de doença do CID conforme sintomas

3- verificar se sugestão esclarece similaridade com sintomas de outras doenças

Dados do diagnostico médico visiveis e disponibilizados no

barramento Kafka fever,blood, headache,cold

acessado a tela de diagnósticos e inserido os sintomas do Ebola e verificado que a inteligencia identificou como caso de Ebola e

dados disponibilizados no Kafka través de mensagens para cada módulo. Efetuado

também os testes com o time TS01.

OK

US211

[META] COMO Usuário do STAMPSNet, DESEJO formatar mensagens de alerta PARA, reportar as devidas autoridades e segmentos

Códigos disponíveis no GitHub mensagens visiveis no broker baseado nos documentos canonicos

Verificar se mensagem foi enviada ao broker

1-acessar site para envio de mensagem 2- enviar uma mensagem 3- visualiza-la no topico especifico do kafka Dados da mensagem visiveis e disponibilizados no barramento Kafka verificar se a mensagem foi disponibilizada no barramento.

Código criado e testado integração com time TS01, conforme categoria de mensagens. Dados disponibilizados no Kafka através de mensagens para cada subsistema conforme

tipo de alerta.

OK

TS02-US10

COMO médico do Projeto de STAMPS, DESEJO cadastrar doenças PARA um fórum de de discussão de diagnóstico com opiniões de outros especialistas da área de saúde

Códigos disponíveis no GitHub Forum disponivel para insercao de posts e leitura de posts

Verificar se forum foi criado 1- acessar o forum2- publicar algum comentario 3- verificar se o mesmo esta visivel

forum disponivel para leitura e

publicacao -item 1 forum

Fórum disponível, e efetuado cadastramento no fórum e criado um post OK

2.3.3 As Burndown Charts das 1ª, 2ª e 3a_Sprints_{do TS#02}

A Sprint 1 foi dedicada a aquisição de conhecimento no domínio da área de saúde, as necessidades e possiblidades de melhoria. E foi dedicado a criação dos cadastros, carga do CID-10 e criação do prontuário

eletrônico. Nesta Sprint também foi elaborada a arquitetura hospedada no Heroku e o framework de desenvolvimento utilizando Phyton. Durante a Sprint as entregas ocorreram próximo ao esperado devido a curva de aprendizado e o produto da Sprint foi entregue de acordo com o prazo final 28 de abril de 2017.

A Sprint 2 foi dedicada a ao aprendizado de métodos preditivos (machine learning, métodos estatísticos e spark) e tecnologias de integração como o Spark. Nesta Sprint houve a participação na elaboração da arquitetura de integração do STAMPsNet e o TS02 trabalhou especificamente na criação dos documentos canônicos para a troca de mensagens e no modelo de incidência para previsão de epidemias. Durante a Sprint as entregas ocorreram próximo ao esperado devido a curva de aprendizado e o produto da Sprint foi entregue de acordo com o prazo final 02 de junho de 2017.

A Sprint 3 foi dedicada a criação do timeline com todos os times envolvidos enviando as mensagens conforme eventos registrados de acordo com a missão atribuída. A inteligência de diagnósticos foi melhorada acrescentando um método probabilístico para diagnóstico de Ebola. Através do cálculo de incidência foi enviado os alertas para hospitais, fornecedores e autoridades para se prepararem para uma crise devido a identificação de um paciente potencial de Ebola. Também foi criado o fórum médico para a discussão entre especialistas entretanto não houve tempo para desenvolver um inteligência para propiciar aprendizados deste módulo. Durante esta Sprint as

(10)

entregas ocorreram antecipadamente, pois dado o aprendizado de novas tecnologias e da estratégia de integração e a reunião no dia 14-Junho pessoalmente com os times, tivemos um ótimo alinhamento sobre as entregas e entregas antecipadas durante toda a Sprint, com o produto final entregue em 24 de Junho de 2017 antes do prazo final 30 de junho de 2017.

Sprint 1 _{Sprint 2}

Sprint 3

Imagem 7 – Burndown Charts

2.4 Uma síntese dos principais pontos positivos e negativos do meu desempenho dentro do

Projeto (Testadora)

Como testadora participei da definição dos testes na primeira semana de cada Sprint e na realização dos testes e preparação das evidencias conforme as tarefas eram completas. E o produto foi validado contra esses casos de testes a cada semana de cada Sprint, através de um processo de desenvolvimento iterativo, onde os requisitos evoluem através da colaboração entre os membros da equipe de desenvolvimento, o proprietário do produto e as partes interessadas.

2.5 Uma síntese das apresentações da CE-229 realizadas na disciplina.

As apresentações foram realizadas nas datas abaixo sendo apresentado os artefatos preparados ao final de cada Sprint:  Apresentação

 User Stories  Casos de Testes  Código no GitHub  Burndown Chart

(11)

 Video

Datas da Apresentação das Sprints:  Sprint 1: 28 de Abril  Sprint 2: 02 de Junho  Sprint 3: 30 de Junho

2.6 Utilização das técnicas de facilitação e coaching para que os membros do TS02

conseguissem visualizar os problemas e encontrar as melhores soluções

Coaching é uma habilidade importante e necessária para cada Scrum Master. Como Scrum Master meu papel foi:  Coaching da Equipe de Desenvolvimento em auto-organização e validação das funcionalidades após a

integração;



Coaching da Equipe de Desenvolvimento em para os membros do time que estavam utilizando e compreendo Scrum pela primeira vez.

 Liderando e treinando o time para a adoção do Scrum;

 Como ScrumMaster e o técnico do Time meu principal papel foi orientar o Time na realização de seus trabalhos, mas não gerenciando o Time ou executando alguma tarefa que seja de responsabilidade do Time; apenas guiando e dando uma direção mais assertiva.

 Ofereci orientações ao time, tentando corrigir o progresso do desenvolvimento em caso de algum atraso. Como Scrum Master ajudei a equipe a definir e aderir ao seu próprio processo para ter certeza que o trabalho fosse feito da melhor forma possível.

2.6.1 Descrição dos artefatos utilizados e como foram guiadas as principais cerimônias, durante o Projeto STAMPS Acadêmico

O Scrum é um Método de Gerenciamento de Desenvolvimento Ágil Pilares: Transparência, Inspeção e Adaptação;

Consiste em times associados a papéis, cerimônias e artefatos.  Papéis: Product Owner, Scrum Master e Development Team;

 Cerimônias: Planning Meeting, Daily Meeting, Review e Retrospective;  Artefatos: Product Backlog, Sprint Backlog e Burndown Chart.

2.7 Uma síntese dos principais pontos positivos e negativos do seu desempenho dentro do

Projeto (Scrum Master)

Como Scrum Master fui bastante suportada pelo time que se demonstrou bastante motivado durante a execução das Sprints, e não houve dificuldade na coordenação das atividades. O produto foi entregue antecipadamente na Sprint 3, e o time estava bem mais confortável tanto com a programação Phyton quanto com a integração via Kafka. Ficou mais claro também como o Índice de Jaccard produziria os resultados adequados para dado os sintomas fosse possível identificar a provável doença do paciente.

(12)

Coordenei as reuniões do time, e também participei das reuniões de Scrum Master para capturar as instruções com foco no projeto e nesta terceira Sprint na integração baseada nas USs globais do STAMPSNet com a publicação de eventos no Timeline, e também a adaptação da inteligência de diagnósticos identificando de forma apropriada que o paciente é suspeito de contaminação por Ebola (conforme descrito na missão atribuída). É mais complexo identificar o Ebola pois os sintomas podem ser confundidos com um gripe comum.

O time se comunicou bem para alavancar a integração prática com os outros times scrum responsáveis pelo os demais subsistemas. E trabalhei na remoção dos empecilhos verificando com os membros do time, com os Scrums Masters dos outros times e com os POs, as dúvidas sobre a integração, sobre os entregáveis do time TS02 e sobre a operação do STAMPSNet.

Como participante da disciplina de testes de software, efetuei a criação e revisão da planilha de testes e executei os testes e verifiquei resultados após a execução neste Sprint 03. As evidencias dos testes foram publicadas juntamente com os casos de testes. A validação da integração foi efetuada verificando o código Phyton.

Na fase de planejamento participei da escolha das USs, planning poker e da criação do Definition of ready e Definition of done, revisão dos critérios de aceitação do PO e da criação da apresentação e relatório sintético. E na conclusão da Sprint no dia 28-Junho, atuei na preparação dos slides para a apresentação final e também verifiquei se estava em conformidade com as heurísticas de apresentação de slides propostas na disciplina CE-245 (Tecnologia da Informação).

Em resumo, tivemos atividades a cada semana, progredimos bem, entregamos a meta e as outras USs que não eram meta. No total foram 1 US Meta global do STAMPSNet, 1 US global do STAMPSNet, e 1 US local descrita especificamente para o módulo de médicos, e que apoiou na inteligência de diagnósticos e no cálculo de incidência da Epidemia. As integrações foram realizadas de forma adequada com os times de TS01-Pacientes e também TS03-Hospitais.

Estou bem feliz com os resultados alcançados, a equipe de trabalho, o desenvolvimento da Sprint e os conhecimentos adquiridos ao estudar as novas tecnologias como Kafka, HL7 e métodos preditivos utilizando métodos estatísticos (Indice de Jaccard) e pela oportunidade de estudar a possível aplicação de machine learning.

3. Conclusão

3.1 Conclusões

2.7.1 Conclusões Específicas

O uso da interdisciplinaridade em 3 cursos de Ciência da Computação funcionou como esperado, uma vez que os alunos conseguiram saber como trabalhar em equipes para desenvolver com sucesso um complexo sistema computacional. O ambiente de computação em nuvem foi amplamente utilizado pelos alunos, de modo a permitir o trabalho colaborativo à distância, usando reuniões locais, sites pessoais e um site oficial do projeto. O quadro Scrum foi adaptado à realidade do ambiente interdisciplinar acadêmico do ITA, ajudando toda a equipe de quase 30 alunos a oferecer valor para as partes interessadas, no final de cada sprint e também no final deste projeto.

A aplicação do Desenvolvimento de Teste de Aceitação (ATDD) no projeto estava intimamente relacionada com a abordagem interdisciplinar adotada, uma vez que os testes de aceitação foram criados por estudantes do curso CE-229, enquanto o software foi implementado por estudantes dos CE-240 e CE-245. O Kafka, Spark, Phyton ou Java, Django e MongoDB

hospedado nos serviços da nuvem Heroku foram as ferramentas aplicadas para modelagem de protótipo e para o processamento automático de dados não estruturados do CID-10. Os resultados deste protótipo do projeto STAMPS foram bem sucedidos, Prof. Cunha e Prof. V. Dias | Time Scrum 02 | 04 de Julho de 2017 P a g e | 11

(13)

Dentre os valores entregues pelo time estão:  Inteligência de Diagnóstico  Cálculo de Incidência de Epidemia

 Arquitetura de Desenvolvimento utilizando o Python

 Ambiente de Médicos integrado com o de Pacientes, Hospitais, Fornecedores a partir da segunda Sprint.  Base do CID disponível em Inglês para utilização pelos Times

Dentre os desfafios enfrentados pelo time TS02:  Dataset para treinar inteligência

 Identificar as mensagens adequadas para cada subsistema  Aprendizado das novas tecnologias, como Spark e Kafka

2.7.2 Conclusões Genéricas

O desenvolvimento acadêmico de um sistema inteligente crítico é uma experiência gratificante, que pode ser usada em diferentes cursos de graduação e graduação. O uso de interdisciplinaridade, computação na nuvem e métodos ágeis parece ser uma nova maneira interessante e motivadora de alcançar objetivos acadêmicos em apenas um semestre de 17 semanas e também pode ser estendido a outros domínios de conhecimento.

2.7.3 Recomendações

Recomenda-se o uso de ferramentas e procedimentos de teste automatizados para acelerar o processo de

desenvolvimento, aumentando a qualidade do produto. As ferramentas de teste de automação que usam o Phyton podem ser usadas para automação, uma vez que elas fornecem alguma automação de testes, mas não houve tempo para que os alunos aproveitassem plenamente isso neste projeto do time TS02.

3.2 Recomendações

Para o aperfeiçoamento deste protótipo, continuidade deste projeto ou projetos futuros, recomenda-se:  Verificar um DataSet de Diagnósticos para Machine Learning

 Substituir serviço de banco de dados MySQL, pois esse não permite uso de triggers, como medida de segurança.  Oportunidade de utilizar Spark na Inteligência de Diagnóstico

 Implementar inteligência para Fórum de médicos, para extrair aprendizados dos especialistas

3.3 Trabalhos Futuros

Sugere-se que o processo utilizado neste projeto STAMPS Academic possa ser estendido a outros projetos de sistemas embarcados, como, por exemplo, no domínio da saúde, na área de vestíveis para rastrear condições de saúde pessoais.

Como trabalho futuro, também é sugerido ampliar a cooperação com a indústria, a fim de obter uma seleção de projetos acadêmicos alinhada às necessidades atualizadas do mercado.

(14)

4. Referências

- STAMPS Acadêmico https://sites.google.com/site/dasamerica2016/stamps_main

- Arquitetura https://docs.google.com/presentation/d/1lzoguCXewFtF705OGEGCJHh2jS-RLYpLJ5slvTOQ5q4/edit#slide=id.g21f85749a4_0_35 - Missão Atribuída https://docs.google.com/document/d/1WfVJs1koafRBN4o5TmlH1zkdJqmC9KhvO72M2eQCIUg/edit - Protocolo da Vigilância http://portalarquivos.saude.gov.br/images/pdf/2014/setembro/01/PROTOCOLO-DE-VIGILANCIA-EBOLA-26-08-VERSAO-6-final.pdf

5. Anexo

A – Artefatos dos testes Sprint 1

US16 – Cadastro de Paramétios e Especialistas

Imagem 8 – Exemplo de Tabela de decisão US16

US10 – Cadastro de médicos

(15)

US03 – Cadastro Prontuário Eletrônico

B- Evidencias dos testes Sprint 1

(16)

US13 – Cadastro de Paramédicos

US10 – Cadastro de Doenças

US03 – Prontuário Eletrônico e Triagem

(17)

C - Artefatos dos testes Sprint 2

US210 – Tabelas e Formato dos documentos Canonicos

Quando anomalia for encontrada pelo sistema, através da inteligência que será implementada em US209, ou algum segmento precisar comunicar-se, poderá ser utilizada a tabela mensagem que armazena eventos e alertas.

Teste do JSON https://search.google.com/structured-data/testing-tool JSON { "resourceType" : "Mensagem", "id": "1", "msg_remetente": "STP", "msg_destinatario": "HOS",

(18)

"msg_conteudo": "5 miles from here, In ITA's was identified a suspect of Ebola Virus. Please, be more attention!",

"msg_data": "01/06/2017 21:20:30", "msg_nivelCriticidade": "HIG" }}

US27 – Inteligencia de Diagnósticos

Verifica doenças quando tem febre (fever)

https://stamps-medicos.herokuapp.com/disease/diseases?disease=fever

(19)

D - Artefatos dos testes Sprint 3

US209 - COMO Usuário do STAMPSNet, DESEJO implementar um processo modelo preditivo, PARA identificar

possíveis alertas.

Acessado a tela de diagnósticos e inserido os sintomas do Ebola e verificado que a inteligencia identificou como caso de Ebola e dados disponibilizados no Kafka través de mensagens para cada módulo.

US211 -

COMO Usuário do STAMPSNet, DESEJO formatar mensagens de alerta PARA, reportar as devidas autoridades e segmentos

Código criado e testado integração com time TS01, conforme categoria de mensagens.

(20)

As evidências dos testes integrados estão registradas nos vídeos.

https://drive.google.com/drive/folders/0B4Xbq1LjOaiSUW5rMHhiZl9zSWc

0 ocorrência

até 4

ocorrências

maior igual 5

ocorrências

Incidência de Paciente

Ebola na Mídia Social

Consultas Médicas

Diagnosticadas Ebola

Solução Mídia Social +

Solução

Consulta Médica

Somatório das

soluções

< 5

Somatório das

soluções >= 5

US10 - COMO médico do Projeto de STAMPS, DESEJO cadastrar doenças PARA um fórum de de discussão de diagnóstico

com opiniões de outros especialistas da área de saúde.

Fórum disponível, e efetuado cadastramento no fórum e criado um post

(21)