Dulce

Abertura

Termo de Abertura do Projeto

1. Introdução

O objetivo do presente documento é fornecer uma visão inicial do projeto Dulce. São listadas as informações priorizadas pelos gestores e stakeholders.

2. Descrição

O projeto Dulce é um sistema que visa gerenciar demandas por meio da análise e monitoramento de indicadores da saúde pública regional (DF).

3. Propósito e Justificativa

A atual situação da saúde pública do DF revela deficiências relacionadas à gerência de insumos. Medicamentos e recursos em falta, equipamentos carentes de manutenção e a quantidade insuficiente de leitos são apenas alguns problemas que causam incômodo à população brasiliense.

Os dados revelam essas ocorrências. Com base nas informações fornecidas, é possível mapear as demandas de insumos de cada unidade pública de serviços de saúde e observar quais possíveis ações reativas devem ser aplicadas.

A solução do software Dulce viabiliza o monitoramento das demandas e deficiências de cada unidade pública de atendimento voltada para o sistema de saúde e, por meio da análise dos dados coletados, pode-se avaliar ações preventivas e reativas que podem ser aplicadas.

4. Objetivos

Dulce tem o propósito de auxiliar a gestão no sistema de saúde do DF, promovendo uma interface entre gestor e servidores de um determinado setor, auxiliando os gestores a criar escalas de servidores, facilitando também o remanejamento de escalas e controle de ponto.

5. Requisitos de Alto Nível

O projeto Dulce será uma plataforma mobile. Entre os requisitos de alto nível elencados temos:

O sistema deve ser de fácil manuseio.

As principais funcionalidades devem ser simples e realizadas de forma a economizar o máximo de tempo possível.

Deve haver uma confidencialidade dos dados presentes no sistema, tendo resguardadas as informações dos pacientes.

O design deve ser simples e minimalista.

6. Riscos

Os principais riscos do projeto são detalhados a seguir.

Risco

Ação Preventiva

Ação Reativa

Adaptação da equipe com as tecnologias

Procurar alunos com experiência para ministrar treinamentos.

Realização de treinamentos sobre tecnologias.

Problemas de equipamentos.

Manutenção.

Pareamento presencial e utilização de equipamentos disponibilizados pela universidade.

Divergência de horários entre os membros do time

Quadro de horários vagos.

Planejamento do pareamento semanal a partir do quadro de horários vagos.

Dificuldade em configurar o ambiente

Auxiliar a equipe de desenvolvimento na configuração de suas máquinas.

Automatizar o ambiente com a ferramenta Docker.

Dificuldades na interação do time

Realizar feedbacks constantes para facilitar a comunicação e o acompanhamento constante dos membros.

Uso do GeekBot para realizar daily meetings pelo Slack e reuniões presenciais três vezes por semana.

Baixa adesão dos usuários à aplicação

Implantar o Fabric.io ou outra ferramenta.

Melhorar o design.

Produto não atende às necessidades do cliente

Reuniões semanais com o cliente.

Identificar os motivos, replanejar e refazer o produto.

Baixa produtividade dos integrantes do grupo

Dar suporte e motivação aos integrantes.

O Scrum Master deve identificar as razões e tentar solucioná-las individualmente. Se necessário, apresentar o problema ao grupo e relatar o ocorrido à professora.

Desistência da disciplina

Integrar e estimular a participação dos integrantes.

Redistribuição de tarefas e melhora do planejamento.

Indefinição do escopo

Reuniões semanais com o cliente.

Buscar alternativas para elicitação de requisitos.

Alteração do escopo

Documentar e refinar os requisitos.

Planejar corretamente a sprint e manter contato frequente com o cliente para ajustar o escopo.

Falta de membros durante as reuniões semanais

Definir datas que a maioria dos membros possam estar presentes.

Alinhamento com o integrante sobre as decisões tomadas.

7. Entregas do produto

O Projeto tem como base duas entregas principais chamadas Release, as datas das Releases foram definidas pela professora para ajustar ao tempo e cronograma das disciplinas de Engenharia do Produto de Software (EPS) e Metodologias de Desenvolvimento de Software (MDS). As possíveis datas para as entregas são:

Release 1 (10/04/2018)

Release 2 (26/06/2018)

8. Estimativa de custo

Recursos Humanos = R$ 75.226,70
Estrutura = R$ 241,20
Notebooks = R$ 20.899,99
Risco = +15%
Total = R$ 96.370,00

Para acessar nossa EVM clique aqui.

9. Partes Interessadas

Cliente

nome, contato

Usuários

* Gestores da Secretaria de Saúde

* Usuários do sistema de escala da Secretaria de Saúde.

Equipe

A equipe é composta por graduandos em Engenharia de Software da Universidade de Brasília pelas disciplinas Engenharia de Produto de Software e Métodos de Desenvolvimento de Software.

PO

Coach

Orientadora

10. Requisitos para a aprovação

O projeto deve atingir as seguintes metas para ser aprovado pelo cliente:

- Implementação das funcionalidades definidas pelo escopo de modo estável;

- Produto guiado pelos requisitos acordados;

- Aprovação das ferramentas de análise de código.

11. Referências

Relatório de Gestão 2016, Universidade de Brasília, pag. 155: Acesso em: 20/03/2018, 22:03, Horário de Brasília.

Risco	Ação Preventiva	Ação Reativa
Adaptação da equipe com as tecnologias	Procurar alunos com experiência para ministrar treinamentos.	Realização de treinamentos sobre tecnologias.
Problemas de equipamentos.	Manutenção.	Pareamento presencial e utilização de equipamentos disponibilizados pela universidade.
Divergência de horários entre os membros do time	Quadro de horários vagos.	Planejamento do pareamento semanal a partir do quadro de horários vagos.
Dificuldade em configurar o ambiente	Auxiliar a equipe de desenvolvimento na configuração de suas máquinas.	Automatizar o ambiente com a ferramenta Docker.
Dificuldades na interação do time	Realizar feedbacks constantes para facilitar a comunicação e o acompanhamento constante dos membros.	Uso do GeekBot para realizar daily meetings pelo Slack e reuniões presenciais três vezes por semana.
Baixa adesão dos usuários à aplicação	Implantar o Fabric.io ou outra ferramenta.	Melhorar o design.
Produto não atende às necessidades do cliente	Reuniões semanais com o cliente.	Identificar os motivos, replanejar e refazer o produto.
Baixa produtividade dos integrantes do grupo	Dar suporte e motivação aos integrantes.	O Scrum Master deve identificar as razões e tentar solucioná-las individualmente. Se necessário, apresentar o problema ao grupo e relatar o ocorrido à professora.
Desistência da disciplina	Integrar e estimular a participação dos integrantes.	Redistribuição de tarefas e melhora do planejamento.
Indefinição do escopo	Reuniões semanais com o cliente.	Buscar alternativas para elicitação de requisitos.
Alteração do escopo	Documentar e refinar os requisitos.	Planejar corretamente a sprint e manter contato frequente com o cliente para ajustar o escopo.
Falta de membros durante as reuniões semanais	Definir datas que a maioria dos membros possam estar presentes.	Alinhamento com o integrante sobre as decisões tomadas.