SISPE - Sistema de Processos de Enfermagem

UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO

PLANO DO PROJETO DO SOFTWARE SISPE -
SISTEMA DE PROCESSOS DE ENFERMAGEM

Eduardo Santana Borges,José Eurique Cardoso Ribeiro Junior,
Ismael dos Santos Silveira, Pablo Felipe Santos Lima

Prof. Dr. Rogério Patrício Chagas Nascimento

São Cristóvão/SE
2018

UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO

Eduardo Santana Borges,José Eurique Cardoso Ribeiro Junior,
Ismael dos Santos Silveira, Pablo Felipe Santos Lima

PLANO DO PROJETO DO SOFTWARE SISPE -
SISTEMA DE PROCESSOS DE ENFERMAGEM

Plano de Projeto de
desenvolvimento de software,
apresentado como requisito total
de avaliação da disciplina
Gerência de Projetos.
Prof. Dr. Rogério Patrício
Chagas Nascimento

São Cristóvão/SE
2018

1.0 INTRODUÇÃO
Esta seção fornece uma visão geral do projeto do software SISPE - Sistema de
Processos de Enfermagem.
1.1 Âmbito do Projeto
O processo de enfermagem é um instrumento metodológico que orienta
o cuidado profissional de enfermagem e a documentação da prática
profissional. Também esclarece que a operacionalização e a documentação do
Processo de Enfermagem evidencia a contribuição da enfermagem na atenção
à saúde da população, aumentando a visibilidade e o reconhecimento do
profissional. Porém, esse instrumento no Hospital Universitário da
Universidade Federal de Sergipe (UFS) ainda é manual. Ou seja, todas as
suas atividades são registradas em formulários de papel, o que além de
ocasionar a lentidão no processo, não proporciona respostas rápidas às
diversas demandas de informação do HU.
Com a implantação do SISPE, espera-se que além de maior agilidade
no processo e interação Paciente - Profissional, a gestão estratégica do
Hospital tenha a seu rápido acesso uma grande gama de dados, que poderão
auxiliar em sua tomada de decisão.
1.2 Funções principais do produto de software
O SISPE terá como principais funcionalidades:
● Manutenir Prescrição;
● Manutenir Diagnóstico;
● Manutenir Necessidade;
● Manutenir Resultados Esperados/Obtidos;
● Recuperar Dados do Paciente;
● Realizar o mapeamento de Necessidades para Diagnósticos;
● Realizar o mapeamento de Diagnósticos para Prescrição;
● Realizar o mapeamento de Prescrição para Resultados Esperados;
● Cadastrar Processos de Enfermagem;
● Gerar Relatório de Evolução de Enfermagem.

Figura 1. Diagrama de Use Case. Fonte: Autoria Própria.
1.3 Requisitos comportamentais ou de performance
● Usabilidade
○ O sistema deve permitir que apenas os gestores tenham
permissão de editar os dados dos pacientes.
○ O usuário não deve passar por mais de oito telas para chegar ao
seu objetivo.
● Interface
○ A interface do sistema deve ser intuitiva.
● Confiabilidade
○ O sistema deve apresentar baixa probabilidade de eventos que
causem falhas.
● Disponibilidade
○ O sistema deve estar disponível a todo o momento, 24 horas/dia
e 7 dias/semana.
● Segurança
○ O sistema deverá ter controle de acesso e de manipulação de
recursos.
○ O sistema deverá garantir a integridade e confidencialidade dos
dados.

● Implantação

○ O sistema deve ser implantado em um ambiente que tenha
conexão com a Internet.
○ É necessário que os usuários passem por um período de
treinamento para aprenderem a manipular o software
corretamente.
1.4 Gestão e Restrições Técnicas
As restrições técnicas do projeto são:
● O sistema deve ser desenvolvido utilizando a linguagem Java.
● O sistema deve utilizar o servidor web Apache Tomcat v7.0 .
● O sistema deve ser desenvolvido utilizando o ambiente de
desenvolvimento Eclipse Java EE IDE.
● Para a construção das interfaces, o sistema deve utilizar o Framework
Java Server Faces (JSF).
● O sistema deve utilizar o banco de dados PostgreSQL.
● O sistema deve utilizar a tecnologia Hibernate para descrever o
mapeamento das entidades no banco de dados.

2.0 ESTIMAÇÕES DO PROJETO
Esta seção fornece as estimações de custo, esforço e tempo. A técnica de
estimação selecionada é a técnica de estimação Orientada a Objetos, aplicada
por Lorenz & Kidd, que é utilizada em Projetos de SW OO da Lacertae
Software.
2.1 Dados históricos utilizados para as estimações
Como se trata do primeiro trabalho realizado pela equipe, não há nenhum
tipo de registro histórico que auxilie na mensuração de estimação de tempo e
esforço para o projeto.
2.2 Técnicas de estimação e resultados
A técnica escolhida para a estimação de tempo foi a técnica de Lorenz & Kidd,
que permite estimar o tempo necessário para a realização do projeto com base
na Orientação a objetos, técnica esta utilizada pela Lacertae Software.
2.2.1 Técnica de estimação
O conjunto de métricas para a estimação selecionado foi definido por Lorenz
& Kidd, onde este modelo baseia-se majoritariamente nas classes chaves e
classes de suporte contidas no projeto. Para a estimação de tempo necessário,
são levados em conta a quantidade de classes-chave, a quantidade de
classes-suporte e fatores de multiplicação de complexidade para a
implementação destas classes.
Para a estimação dessa complexidade, é utilizada uma tabela de
estimação proposta pelos autores, onde para cada tipo de interface, seja ela
uma graphical user interface (GUI) ou não, é associado um grau de
complexidade:
Interface Multiplicador
Não-gráfica 2
Baseada em Texto 2,25
GUI 2,5
GUI Complexa 3
Tabela 1: Estimação de complexidade baseada em interface. Autores: Lorenz & Kidd.

A métrica de Lorenz & Kidd fundamenta-se nos seguintes passos:
1.Especificação da quantidade de classes-chaves do sistema;
2.Classificação do tipo de Interface utilizada nas classes chave para a
determinação do fator de multiplicação, fator este que será necessário para
determinar a quantidade de classes de suporte necessárias para cada
classe-chave.
3.Multiplicação da quantidade de classes-chave pelo multiplicador
correspondente da Tabela a fim de estimar o número de classes de suporte
para cada uma das classes-chave.
4.Multiplicar o total de classes identificadas, isto é, a soma das classes-chave e
classes de suporte , pelo número médio de unidades de trabalho.
5.Obter o total de dias previstos para a realização das classes do projeto.
6.Dividir o total de dias pela quantidade de membros da equipe e assim obter a
quantidade de dias úteis por pessoa para concluir o projeto.
7.Adequar a quantidade de dias úteis por pessoa obtidas no Item 6 e levar em
consideração fatores como finais de semana, feriados, pontos facultativos e
ausência de colaboradores por motivos como doença, viagens, treinamentos,
certificações, etc.
8.Obter tempo total para a execução do projeto.
2.3 Resultados
Aplicada a técnica de estimação de Lorenz & Kidd no diagrama de classes de
domínio presente no Anexo, podem-se obter os seguintes resultados:
1. Classes-chave identificadas: 13 sendo: Profissional, Leito, Unidade,
Paciente, PacienteEntrada, TransOperatorio, TransPosOperatorio,
ProcessoEnfermagem, Diagnostico ,Necessidade, OpcaoNecessicade,
Prescricao e ResultadoEsperadoObtido.
2. Tipos das classes de suporte: GUI (Graphical User Interface), com valor
multiplicador de 2,5.
3. Cálculo de classes de suporte: 13 (classes-chave) x 2,5 (Multiplicador)
= 33 classes de suporte.
4. Total de classes no sistema: 13 (chave) + 33 (suporte) = 46 classes.
5. Número médio de unidades de trabalho dia/pessoa: 16,5.(valor obtido
através da média estimada de esforço por cada membro da equipe). Logo
Tempo bruto previsto:
6. Tempo útil por pessoa previsto: 46 * 16,5 = 759 dias por pessoa.
Considerando o fato de que a equipe possui 4 colaboradores: 759/4 = 190 dias
por membro da equipe.
7. Levando em consideração ainda que um mês possui em média 20 dias
úteis de trabalho, isto é, descontando-se fatores como finais de semana,
feriados, pontos facultativos e ausência de colaboradores por motivos como

doença, viagens, treinamentos, certificações, etc. Temos o total de 9,5 meses
para o desenvolvimento do projeto.
2.4 Recursos do projeto
Recursos humanos, de software e hardware, ferramentas de apoio e
outros recursos necessários foram descritos a seguir.
2.4.1 Recursos Humanos
Para o desenvolvimento do projeto, foram utilizados 4 colaboradores, onde
cada um deles poderia rotacionar os papéis executados com base na utilização
da metodologia ágil e cultura Dev-Ops. Cada um dos colaboradores é
responsável por selecionar uma tarefa, implementá-la e testá-la de acordo
com os casos de testes necessários à funcionalidade.
Foram ajustadas 10 Sprints, com duração de 30 dias cada para o
gerenciamento do projeto. Em cada uma das Sprints, o papel de Scrum
Master era rotacionado entre os colaboradores. Cada uma das Sprints possui
o carregamento de 60% da sua carga total de trabalho, onde os 40%
remanescentes devem ser utilizados para a implementação de casos de testes
e correção de bugs.
O ciclo de planejamento das Sprints foi alocado de maneira que cada
um dos integrantes assumisse o papel de Scrum Master durante a Sprint.
Uma vez completado a rotação do papel de Scrum Master, o ciclo se repete.
Dessa forma, podemos apresentar a definição de uma Sprint seguinte
maneira:
2.4.2 Recursos de Software
Para o desenvolvimento do projeto foram utilizados os seguintes softwares/
ferramentas:
● Eclipse: IDE com suporte ao desenvolvimento de projetos em Java;
● Trello: ferramenta com suporte à metodologia Kanban para o
gerenciamento das atividades;
● ScrumHalf: ferramenta de gerenciamento de sprints e projetos
baseados na metodologia ágil;
● PostGreSQL: Banco de dados para o armazenamento das informações;
● GitHub: ferramenta de controle e versionamento do projeto;
● MySQL workbench: software destinado à modelagem dos dados;
● Bizagi Modeler: ferramenta de notação e modelagem de processos
(BPMN)

2.4.3 Recursos de Hardware
Foram utilizados 4 notebooks para o desenvolvimento do projeto
3.0 ANÁLISE E GESTÃO DE RISCOS
Nesta seção são discutidos os riscos do projeto e como geri-los. A identificação
do risco é uma tentativa sistemática de especificar ameaças ao plano do
projeto (estimativas, cronograma, recursos e etc). Ao identificar e analisar
riscos conhecidos e previsíveis, o gerente de projeto dá o primeiro passo no
sentido de evitá-los quando possível e controlá-los quando necessário. É
importante lembrar que, ao se elicitar riscos, muitas vezes não é possível
identificar todos as ameaças a que o projeto está exposto, isso se deve a
instabilidade do mundo e às limitações, físicas e intelectuais, do próprio
analista, por esta razão, experiência e uma base de conhecimento são
requisitos essenciais para uma boa análise de risco. Todavia, a inexistência
de experiência anterior não deve ser um empecilho para se efetuar a análise e
a gestão de risco por dois motivos evidentes, o primeiro resume-se em no fato
que esta base de conhecimento jamais será criada se não for dado o primeiro
passo e o segundo diz respeito à constatação de que o simples exercício de
pensar sobre o que pode dar errado pode ajudar o gestor e a equipe a se
preparar melhor para as situações adversas.
3.1 Riscos do projeto
Riscos sempre se referem a acontecimentos futuros, e possuem certa margem
de incerteza. Um problema que certamente ocorrerá e não pode ser evitado
não deve ser tratado como um risco e sim como um obstáculo a ser contornado
ou superado. Riscos residem no campo da incerteza, e sempre possuem uma
probabilidade de ocorrência entre 0 e 1.
No contexto da gerência de projetos de software, riscos podem ser de
três tipos, são eles: riscos de projeto, riscos técnicos e riscos de negócio.
Riscos de projeto ameaçam especificamente o plano de projeto, eles
podem atrasar o cronograma e elevar consideravelmente os custos, além de
identificar problemas com recursos, cronograma, pessoal e orçamento, por
exemplo.
Riscos técnicos ameaçam a qualidade e data de entrega do software a
ser produzido. Este tipo de risco pode dificultar a implementação, e/ou a
manutenção, da solução ou tornar essa implementação, e/ou manutenção,
impossível. Isto decorre da subestimação da dificuldade de resolver certo
problema técnico.

Riscos de negócio ameaçam a viabilidade do software a ser criado e
muitas vezes ameaçam o projeto ou o produto. Um bom exemplo de risco de
negócio é criar um produto que o mercado não está interessado, observe que
não existe qualquer problema do ponto de vista da execução do trabalho,
entretanto é muito impactante para o projeto pois representa uma ameaça de
o trabalho empregado na construção do produto, e portanto, o investimento,
não seja compensado pela aceitação do produto pelos clientes/usuários.
A análise dos riscos do projeto é feita em duas etapas, a primeira
consiste no estabelecimento de uma matriz de dano, a segunda, na
enumeração de cada um dos riscos a que o projeto está exposto junto com
suas respectivas probabilidades de ocorrência. Neste trabalho, parte-se da
premissa de que a equipe não possui dados históricos para basear a análise,
por essa razão as probabilidade aqui apresentadas são baseadas em
conhecimento tácito dos analistas e não devem ser consideradas precisas,
sendo, portanto, meramente ilustrativas.
A seguir apresentamos a matriz de dano:
Matriz de
Impacto Catastrófico Crítico Médio Marginal Desprezível
Inexiste
nte
Dano 5 4 3 2 1 0
Tabela 2: Matriz de dano adaptada do método FAA com mais gradações.
Como apresentado, a matriz de dano possui 6 categorias, estas
decorrem de uma simplificação do dano real que pode ser mapeado
diretamente para uma faixa de valores monetários, ou qualquer outro
representante de custo, com facilidade.
Conseguinte, apresentamos a matriz de riscos que foi construída
perante a análise do projeto. É importante salientar que esta matriz não é
definitiva e pode mudar ao longo da execução do projeto, as probabilidades
aqui obtidas não seguem nenhum processo processo formal, entretanto, em
um cenário com dados reais, podem ser estimadas por meio de métodos como
regressão logística ou raciocínio de classificação probabilístico como o Naive
Bayes.
Risco Tipo
Abordagem de garantia de qualidade não definida Projeto
Revisão técnica informal Projeto
Não integração entre ferramentas de processo Projeto
Documentação desatualizada Projeto
Quantidade insuficiente de colaboradores Projeto

Desenvolvimento paralelo de com outros projetos Projeto
Escassez de equipamento e recursos para desenvolvimento Técnico
Indefinição de métricas para monitoramento Técnico
Problemas de performance por obsolescência da arquitetura Técnico
Seleção de modelo de processo inadequado Técnico
Consultas complexas por causa do desenho do banco de dados Técnico
Possível mudança de processo Negócios
Mudança de regulação Negócios
Problemas na integração com outras áreas fins do negócio Negócios
Requisitos funcionais não corretamente elicitados Negócios
Ausência de estimativas do volume de armazenamento Técnico
Sobrecarga do sistema com grande número de usuários Técnico
Time desmotivado Projeto
Tabela 3: Riscos identificados no projeto.
3.2 Tabela de riscos
Nesta seção, apresenta-se os riscos devidamente ponderados pelo dano
causado em caso de sua ocorrência, a análise de quão arriscado é executar o
projeto decorre do valor, R, da exposição ao risco, que, quando computada,
não deve ser superior a 50% (cinquenta por cento) para tornar o projeto
minimamente viável.
Risco Probablidade Impacto
Problemas de performance por obsolescência da
arquitetura 0,30
5 -
Catastrófico
Escassez de equipamento e recursos para
desenvolvimento 0,90
5 -
Catastrófico
Seleção de modelo de processo inadequado 0,15
5 -
Catastrófico
Possível mudança de processo 0,70
5 -
Catastrófico
Mudança de regulação 0,30
5 -
Catastrófico
Problemas na integração com outras áreas fins do
negócio 0,30
5 -
Catastrófico
Requisitos funcionais não corretamente elicitados 0,10
5 -
Catastrófico

Quantidade insuficiente de colaboradores 0,70
5 -
Catastrófico
Abordagem de garantia de qualidade não definida 0,30 4 - Crítico
Revisão técnica informal 0,65 4 - Crítico
Documentação desatualizada 0,70 4 - Crítico
Time desmotivado 0,90 4 - Crítico
Desenvolvimento paralelo de com outros projetos 0,85 4 - Crítico
Consultas complexas por causa do desenho do
banco de dados. (Consultas Externas (Análise por
ponto de função) complexas) 0,80 4 - Crítico
Indefinição de métricas para monitoramento 0,30 3 - Médio
Não integração entre ferramentas de processo 0,65 3 - Médio
Sobrecarga do sistema com grande número de
usuários 0,30 2 -Marginal
Ausência de estimativas do volume de
armazenamento 0,80
1 -
Desprezível
Tabela 4: Atribuição de probabilidade aos riscos identificados.
Feito isto, agora, basta obter o somatório das probabilidades
multiplicados pelo seu impacto. Chamemos este valor S, S = 38,3. Um vez
computado o valor de S, calculamos ST, que consiste no impacto no pior
cenário, ou seja, o impacto quando todos os riscos ocorrem. Para obter o valor
de ST basta somar o impacto de todos os riscos individualmente, ST = 73. Por
fim pode ser calculado a exposição ao risco, R, que consiste na razão simples
entre S e ST, R ~ 0,52, ou 52%. Visto que R é maior que 50%, percebe-se que
alguns riscos precisam ser mitigados antes do início do projeto.
3.3 Redução e Gestão do Risco
Nesta seção são numerados individualmente 8 (oito) dos riscos mais
importantes do projeto junto a um breve roteiro de ações para mitigá-los e,
ou, gerí-los. Para tal objetivo, é apresentado um conjunto de ações
alternativas, ou ações de contingência, com o objetivo de diminuir um dos dois
fatores que compõem o dano causado pelo risco em particular, ou seja, a
probabilidade ocorrência ou o impacto. A constante prática da atividade de
redução e gestão do risco pode reduzir sensivelmente a exposição ao mesmo
demonstrada na seção anterior e aumentar a viabilidade do produto a ser
construído.
1. Abordagem de garantia de qualidade não definida

Impacto 4 - Crítico
Probabilidade 30%
Estratégias de
redução
Definir a estratégia de garantia de
qualidade em sua totalidade
formalizada de maneira
documentada;
Selecionar e estabelecer padrões e
normas a serem seguidos.
Plano de
contingência
Adotar, ou desenvolver, uma
estratégia de garantia de
qualidade minimamente aceita
pelo cliente.

Mais detalhes: É possível
contornar este risco através do
estabelecimento das práticas de
garantia de qualidade a serem
seguidas pelo time de
desenvolvimento durante a
construção do produto. Essas
práticas devem ser aprovadas
pelo cliente para garantir que o
produto se adequa às suas
necessidades.
Responsável Analista de Quality Assurance.
2. Revisão técnica informal
Probabilidade 65%
Estratégias de
redução
Formalizar a técnica de revisão.
Plano de
contingência
Adotar a técnica de revisão por
pares preconizada pela filosofia
eXtreme Programming.

Mais detalhes: Pode-se utilizar a
revisão por pares com o objetivo
de formalizar a revisão através

de um método bem difundido e
mais formal que o atual.
Responsável Engenheiro de Software.
3. Não integração entre ferramentas de processo
Impacto 3 - Médio
Probabilidade 65%
Estratégias de
redução
Adquirir suíte de software que
possui integração garantida
pelo fabricante;
Desenvolver componentes que
efetuem a integração das
ferramentas utilizadas
atualmente.
Plano de
contingência
Utilizar software não integrado,
porém seguindo processos bem
estabelecidos e modelos
predefinidos.

Mais detalhes: Estabelecer
padrões para documentos e
processos deve sanar a
necessidade de integração entre
as ferramentas, de forma a
permitir que os trabalhadores
produzam artefatos
compatíveis mesmo utilizando
ferramentas pouco integráveis.
Responsável Gerente de projetos.
4. Documentação desatualizada
Probabilidade 70%
Estratégias de
redução
Dedicar tempo de trabalho para
refinar e atualizar a
documentação inicial do
produto.

Plano de
contingência
Utilizar ferramentas de
engenharia reversa para obter
um relatório e, possivelmente,
diagramas do estado atual da
ferramenta.

Mais detalhes: Pode-se utilizar
ferramentas de engenharia
reversa que recebem como
entrada o código-fonte do
produto e produz diagramas de
classes para o mesmo de acordo
com o estado atual de
desenvolvimento sem maiores
esforços humanos.
Responsável Engenheiro de Software.
5. Quantidade insuficiente de colaboradores
Impacto 5 - Catastrófico
Probabilidade 70%
Estratégias de
redução
Contratar mais colaboradores;
Diminuição do escopo do projeto.
Plano de
contingência
Negociar mais prazo ou aumento
do orçamento para arcar com
horas extras.

Mais detalhes: Aumentar os
valores das variáveis
relacionadas ao prazo e o custo
de produção de forma a suprir a
ausência de profissionais
capazes de executar o projeto
com mais celeridade. O
aumento do custo permite a
contratação de mais
colaboradores, já o aumento do
prazo permite que os
colaboradores existentes
tenham mais tempo para
agregar funcionalidades ao

produto.
6. Desenvolvimento paralelo de com outros projetos
Probabilidade 85%
Estratégias de
redução
Executar projetos em série para
evitar a troca de contexto dos
desenvolvedores.
Plano de
contingência
Subdividir a equipe para que cada
subgrupo trate dos vários
projetos individualmente.

Mais detalhes: Utilizar a técnica
de solução de problemas
chamada “dividir para
conquistar” e criar times
menores capazes de focar
individualmente de forma
paralela nos projetos
concomitantemente.
7. Escassez de equipamento e recursos para desenvolvimento
Impacto 5 - Catastrófico
Probabilidade 90%
Estratégias de
redução
Adquirir ferramentas e recursos
para o desenvolvimento;
Desenvolver ferramentas básicas
para ajudar no
desenvolvimento do produto
principal.
Plano de
contingência
Utilizar ferramentas de uso
irrestrito, como software livre.

Mais detalhes: Através da

utilização de software livre é
possível obter uma satisfatória
gama de equipamentos e
recursos sem pesar no
orçamento do projeto.

8. Indefinição de métricas para monitoramento
Impacto 3 - Médio
Probabilidade 30%
Estratégias de
redução
Estabelecer método formal,
preferencialmente
automatizado, para
levantamento e
armazenamento de métricas.
Plano de
contingência
Colher e registrar métricas de
maneira manual.

Mais detalhes: Na ausência de
ferramentas automatizadas e
um método formal, é possível
utilizar técnicas como GQM
(Goal - Question - Metrics) para
estabelecer métricas e geri-las
manualmente.
Responsável Analista de Quality Assurance.

4.0 PLANEAMENTO TEMPORAL
O planejamento seguiu metodologias ágeis. Assim como a entrega dos
módulos e tarefas diárias será definida pelo time de desenvolvimento. Dessa
forma, cada módulo foi dividido em CRUD’s (create, read, update, delete), que
são operações padrões em projetos com objetos relacionais. Assim,
simplificamos o processo de controle de tempo. Cada processo inclui interface
e lógica (front e back end). Além disso foi adicionado tempo extra para

relacionamentos de entidades, como descrito no diagrama de classes,
constante no Anexo I deste documento.
4.1 Conjunto de Tarefas do Projeto
O projeto foi dividido em 10 Sprints, que irão cobrir as atividades de
Elicitação de Requisitos, Desenvolvimento, Testes e a entrega do produto de
software. As Sprints estão listadas abaixo, com cada integrante da equipe em
seus respectivos papéis.
Sprint 1
Scrum Master: Pablo Felipe
Time de Desenvolvimento: Eduardo Borges, José Eurique, Ismael
Silveira.
Carga: 60% da capacidade total.
Duração: 20 dias úteis (1 mês).
Sprint 2
Scrum Master: Eduardo Borges
Time de Desenvolvimento: Pablo Felipe, José Eurique, Ismael Silveira.
Sprint 3
Scrum Master: José Eurique,
Time de Desenvolvimento: Pablo Felipe, Eduardo Borges, Ismael
Silveira.
Sprint 4
Scrum Master: Ismael Silveira.
Time de Desenvolvimento: Pablo Felipe, Eduardo Borges, José
Eurique.
Sprint 5

Silveira.
Sprint 6
Scrum Master: Eduardo Borges
Time de Desenvolvimento: Pablo Felipe, José Eurique, Ismael Silveira.
Sprint 7
Scrum Master: José Eurique,
Time de Desenvolvimento: Pablo Felipe, Eduardo Borges, Ismael
Silveira.
Sprint 8
Scrum Master: Ismael Silveira.
Time de Desenvolvimento: Pablo Felipe, Eduardo Borges, José
Eurique.
Sprint 9
Silveira.

Sprint 10
Implantação e Treinamento de usuários.
Duração: 20 dias úteis (2 semanas).

4.2 Diagrama de Gantt
O diagrama de Gantt consta no Anexo II deste documento. É importante
ressaltar que ao utilizarmos métodos ágeis, não estamos adotando a
estrutura tradicional, conhecida como 4-2-4, que representam
respectivamente, 40% de tempo para especificação, 20% de tempo para
desenvolvimento e 40% para testes e evolução de software.
5.0 ORGANIZAÇÃO DO PESSOAL
Nesta seção, iremos apresentar a estrutura, forma de organização, e mecanismos de
comunicação da equipe.
5.1 Estrutura da equipe
RESPONSÁVEL PAPEL DESCRIÇÃO
Pablo Felipe Santos
Lima
Gerente de
Projetos /
Desenvolvedor
Exerce a função de planejar e
controlar a execução do
projeto, de forma a conduzir
melhor a equipe. Atua
também como desenvolvedor
do sistema.

José Eurique Cardoso
Ribeiro Júnior
Analista de
Sistemas /
Desenvolvedor
Tem a função de planejar o
sistema, realizando o
levantamento de requisitos,
mapeamento dos processos,
modelagem de dados, além de
atuar na promoção e garantia
da qualidade do produto. Atua
do sistema.
Eduardo Santana
Borges
Testador /
Desenvolvedor
Atua também como
desenvolvedor do sistema.
Também é responsável por
realizar testes mais rigorosos
de integração e implantação
do sistema.
Ismael dos Santos
Silveira
Testador /
Desenvolvedor
Responsável por construir e
realizar os casos de testes, a
fim de verificar o
funcionamento do software,

garantindo que ele atenda aos
requisitos levantados. Atua
do sistema.

5.2 Mecanismos de comunicação
A comunicação foi feita por meios eletrônicos e presenciais, a saber:
● Correio Eletrônico, para comunicações mais formais que necessitam de
registro, e posterior consulta;
● Trello, para registro das tarefas, possíveis dependências, e comunicação entre
o time;
● Reuniões presenciais para alinhamento das ideias do time;
● WhatsApp, ferramenta de fácil acesso e de rápida comunicação entre o time.
5.3 Uso do Edu-blog como ferramenta de apoio
O edu-blog foi fundamental no intuito de descentralizar e fornecer todo o conteúdo
necessário para elaboração deste documento de plano de projeto, e dos seminários da
disciplina.
Por meio do edu-blog tivemos acesso aos edu-blogs de turmas passadas. O que além
de dirimir as dúvidas que tínhamos na construção deste documento, enriqueceu este
trabalho, pois há material desde 2015, de diferentes produtos de software. Se a
disciplina se limitasse somente ao ambiente virtual disponibilizado pelo Sistema
Acadêmico da Universidade, não teríamos esses conteúdos tão facilmente
disponibilizados no blog de apoio à disciplina. Desta forma, podemos concluir que o
edu-blog cumpriu seu papel para nossa aprendizagem.
6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A
QUALIDADE DO PRODUTO DE SW
Para garantir a qualidade do produto disponibilizado seguimos algumas normativas:

● Geração de documentação de apoio, de forma à garantir a evolução do
Sistema.
● Testes unitários, de integração e de sistema, que foram realizados por um
membro da equipe diferente de quem desenvolveu.
● Adoção de práticas ágeis, tanto para estimação, quanto para a planificação
deste projeto, com o auxílio de técnicas como o Planning Poker.

● Estudo e aplicação dos padrões de qualidade do produto, da família ABNT
ISO/IEC: 25000.

SISPE - Sistema de Processos de Enfermagem

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a SISPE - Sistema de Processos de Enfermagem

Semelhante a SISPE - Sistema de Processos de Enfermagem (20)

SISPE - Sistema de Processos de Enfermagem