Plano de projeto

Universidade Federal de Sergipe
Centro de Ciências Exatas e Tecnologia/CCET
Departamento de Computação/DCOMP
Gerência de Projetos
Prof.º Dr.º Rogério Patrício Chagas do Nascimento
Sistema +Paciente
Plano de Projeto de Software
Allan Silva Santos
Antonio Carlos Martins Pereira Junior
Diego Rodrigues Santos
Icaro Pereira Prado
Lucas Mateus de Santana Cruz
São Cristóvão – SE
Fevereiro 2019

Universidade Federal de Sergipe
Centro de Ciências Exatas e Tecnologia/CCET
Departamento de Computação/DCOMP
Gerência de Projetos
Prof.º Dr.º Rogério Patrício Chagas do Nascimento
Sistema +Paciente
desenvolvido na disciplina de Gestão
de Projetos para obtenção de nota.
São Cristóvão - SE
Fevereiro 2019
1

Sumário
1. INTRODUÇÃO 3
1.1 ÂMBITO DO PROJETO 3
1.2 FUNÇÕES PRINCIPAIS DO PRODUTO DE SOFTWARE 4
1.3 REQUISITOS COMPORTAMENTAIS OU DE PERFORMANCE 6
1.4 GESTÃO E RESTRIÇÕES TÉCNICAS 9
2. ESTIMAÇÕES DO PROJETO 9
2.1 TÉCNICAS DE ESTIMAÇÃO E RESULTADOS 9
2.1.1 TÉCNICA DE ESTIMAÇÃO 9
2.1.2 RESULTADOS 11
2.2 RECURSOS DO PROJETO 12
2.2.1 RECURSOS HUMANOS 12
2.2.2 RECURSOS DE SOFTWARE 12
2.2.3 RECURSOS DE HARDWARE 13
3. ANÁLISE E GESTÃO DE RISCOS 13
3.1 RISCOS DO PROJETO 14
3.2 REDUÇÃO E GESTÃO DO RISCO 15
4. PLANEJAMENTO TEMPORAL 21
4.1 CONJUNTO DE TAREFAS DO PROJETO 21
4.2 DIAGRAMA DE GANTT 21
5. ORGANIZAÇÃO DO PESSOAL 27
5.1 ESTRUTURA DA EQUIPE 27
5.2 MECANISMOS DE COMUNICAÇÃO 28
5.3 USO DO EDU-BLOG COMO FERRAMENTA DE APOIO 28
5.4 FERRAMENTAS DE GESTÃO DO PROJETO 28
6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A
QUALIDADE DO PRODUTO DE SOFTWARE 29
7. REFERÊNCIAS 30
8. APÊNDICE 1 - DIAGRAMA DE GANTT DO PLANEJAMENTO TEMPORAL 31
2

1 INTRODUÇÃO
O objetivo deste documento é descrever uma visão geral do plano de
projeto de software do sistema +Paciente, desenvolvido em prol da melhoria no
atendimento público aos pacientes do Hospital Universitário de Sergipe (HU).
Este plano apresenta abordagens da Gestão de Projetos e da Engenharia de
Software, bem como os requisitos funcionais, não-funcionais e inversos, casos
de uso e stakeholders do projeto.
1.1 Âmbito do Projeto
O sistema +Paciente se destina aos pacientes internos e externos do
Hospital Universitário (HU) que necessitam de informações sobre todas as
etapas da realização de uma cirurgia, que compreendem desde da comprovação
de necessidade cirúrgica até o período pós-cirúrgico. Além disso, o sistema tem
como objetivo prover informações úteis aos acompanhantes que estão junto a
um paciente internado e médicos que necessitam auxiliá-los sobre os
procedimentos cirúrgicos que devem ser realizados, elevando assim a eficiência
do atendimento e realização de cirurgia.
Um dos principais problemas no HU/UFS atualmente é o procedimento
informacional de pacientes sobre consultas, documentação necessária,
recomendações e situações pré-cirúrgicas/pós-cirúrgicas. Outro problema de
caráter crítico é a comunicação do HU com o paciente, pois são realizadas
inúmeras ligações telefônicas para o agendamento de uma cirurgia ou consulta,
muitas vezes não havendo feedback do paciente.
Além de existir bastante burocracia para a realização de cirurgias, o
procedimento cirúrgico está sendo agendado em última hora, uma vez que os
3

pacientes não têm o total conhecimento de como proceder após sua consulta no
HU/UFS. Outro problema está na tomada de conhecimento da cirurgia no último
minuto. Isso ocorre devido à desinformação do paciente quanto ao prazos de
autorizações, termos e realização de exames e a dificuldade do HU em
contactá-lo.
A aplicação +Paciente auxiliará o Núcleo Interno da Regulação e o setor
de Coordenação de Centro Cirúrgico, automatizando e agilizando o acesso às
informações de forma geral, diminuindo o tempo de espera dos pacientes para a
realização da cirurgia e melhorando o canal de comunicação entre médico e
paciente.
1.2 Funções principais do produto de software
A Figura 1 mostra uma simples representação do diagrama UC (Use
case) do +Paciente. Nele, são exibidos os atores que interagem com o sistema
proposto, bem como as ações (os casos de uso) que cada ator pode realizar
seguido das suas principais funções.
Figura 1 – Diagrama de Caso de Uso do +Paciente
4

O diagrama de classes de domínio do sistema +Paciente é demonstrado
na Figura 2, que apresenta as principais funcionalidades descritas no diagrama
de casos de uso mostrado na Figura 1.
Figura 2 – Diagrama de classes do +Paciente
Fonte: Autores.
5

1.3 Requisitos comportamentais ou de performance
Os requisitos comportamentais ou de performance são os requisitos
não-funcionais apresentados abaixo. Tratam daqueles que são necessários para
que as funcionalidades do sistema sejam alcançadas de forma que apresente
qualidade. Entre eles estão qualidade, usabilidade, desempenho e segurança,
além da definição de quais são os requisitos de implantação e requisitos de
hardware e software.
1.3.1 Usabilidade
Esta subseção descreve os requisitos não-funcionais associados à
facilidade de uso da aplicação.
Meios de Acesso ao Sistema
As interfaces do sistema devem ser acessíveis em um Web Browser, seja
em computador, celular ou tablet.
Prioridade: ☒ Essencial ☐ Importante ☐ Desejável
1.3.2 Confiabilidade
freqüência e severidade de falhas da aplicação e habilidade de recuperação das
mesmas.
Notificação de Falha
O sistema deve exibir uma notificação de falha de acesso quando não
houver conexão com o banco de dados ou a internet.
Prioridade: ☐ Essencial ☒ Importante ☐ Desejável
6

1.3.3 Desempenho
eficiência, uso de recursos e tempo de resposta da aplicação.
Tempo máximo de resposta
O tempo de resposta no que se refere às funcionalidades do sistema não
deve ultrapassar 10 segundos.
Tempo de Inatividade
A sessão de acesso via tablet, celular ou computador deverá expirar após
15 minutos em caso de inatividade.
1.3.4 Segurança
integridade, privacidade e autenticidade dos dados da aplicação.
Identificação de Usuário
O paciente deverá ser identificado no sistema exclusivamente por meio
do seu número de prontuário.
Vínculo de Acompanhante a um Paciente
Todo acompanhante deverá obrigatoriamente ser associado ao número
de identificação de um ou mais pacientes.
7

Identificação de Pacientes
Todo acompanhante deverá ser associado ao número de identificação de
um ou mais pacientes.
Notificação de Expiração
O sistema deverá vetar o acesso das informações dos pacientes e
acompanhantes após 30 dias da finalização da cirurgia e notificar o paciente
cadastrado acerca da expiração do seu acesso.
Notificação de Autorização
O sistema deve lembrar o paciente após 15 dias da realização da
consulta de avaliação cirúrgica que ele necessita do documento de autorização
IEH.
1.3.1 Hardware e software
Esta seção descreve os requisitos não funcionais associados ao
hardware e software usados para desenvolver ou para executar a aplicação.
Conexão com a Internet
O usuário precisará de uma conexão com a internet para conectar ao
sistema +Paciente.
8

1.4 Gestão e Restrições Técnicas
As restrições técnicas associadas ao desenvolvimento do projeto são:
● O sistema deverá ser implementado na linguagem de programação
Java versão 7 com framework JavaServer Faces (JSF) e/ou
primefaces, spring, podendo ser utilizado javascript, jquery;
● O Sistema Gerenciador de Banco de Dados (SGBD) utilizado deve
ser o PostgresSQL versão 9.1 ou superior.
2 ESTIMATIVAS DO PROJETO
As estimativas que serviram como base ao desenvolvimento do projeto
+Paciente foram calculadas de acordo com as métricas de Lorenz e Kidd
(LORENZ M.; KIDD, 1994). Essas métricas foram escolhidas por se adequarem
bem ao desenvolvimento de software construídos de acordo com o paradigma
da orientação a objetos, como é o caso deste software. Esta seção fornece as
estimações de custo, esforço e tempo para realização do projeto.
2.1 Técnicas de estimativa e resultados
Esta subseção descreve a técnica utilizada para o desenvolvimento do
projeto e os resultados encontrados.
2.1.1 Técnica de estimação
A técnica de Lorenz e Kidd (1994) consiste, basicamente, em aspectos
baseados no diagrama de classes (Figura 2) definido para o projeto. Suas
etapas são as seguintes:
1. Definir a quantidade de classes chave, ou seja, o número de classes
ligadas diretamente às regras de negócio;
2. Definir o número de classes de suporte/apoio. Para isso é necessário
classificar o tipo de interface do sistema e associá-la a um
9

multiplicador de acordo com sua complexidade. O quadro 1 exibe a
complexidade para a interface do produto.
Quadro 1 - Multiplicadores por interface para classes chave.
Interface Multiplicador
Não gráfica 2
Baseada em texto 2,25
GUI 2,5
GUI Complexa 3
Fonte: Lorenz e Kidd (1994)
3. Após a definição das classes chave e associá-lo ao multiplicador, é
necessário multiplicar a quantidade de classes chave definida pelo
multiplicador para obter uma estimativa do número de classes de
suporte, sendo número de classes chave X multiplicador
correspondente;
4. Logo após, calcula-se a quantidade total de classes, somando o
número de classes chave selecionadas na primeira etapa com o
número de classes de suporte, resultado encontrado na terceira
etapa;
5. Próximo passo é multiplicar a quantidade total de classes, calculada
no passo anterior, pelo número médio de unidades de trabalho
(dia-pessoa) por classe. Onde os membros do projeto devem
selecionar entre 15 a 20 dias-pessoa por classe e justificar a escolha
(Lorenz & Kidd). O resultado é a estimativa de tempo necessário para
desenvolver o projeto;
E como resultado da aplicação dos passos descritos, obtém-se a
estimativa do tempo necessário para a realização do projeto.
10

2.1.2 Resultados
A utilização das métricas foi aplicada de acordo com o diagrama de
classes (Figura 2) definido para o projeto +Paciente com base nas métricas
definidas por Lorenz e Kidd (1994). Assim, os resultados gerados pela aplicação
da técnica são:
1. Quantidade de classes chave: 11 (Pessoa, Chefe, Relatorio,
Medico, Paciente, Cirurgia, Acompanhante, Atendente,
AcoesFacade, Cardapio, Mapa);
2. Todo o sistema é baseado em uma interface gráfica simples (GUI),
logo atribui-se o multiplicador 2,5;
3. Agora calcula-se o número de classes de suporte, sendo o nº de
classes chave X fator multiplicador, ou seja, 11 x 2,5 = 27,5;
4. Assim, o total de classes projetadas para o sistema será 11
(classes chave) + 27,5 (classes de suporte) = 38,5.
5. O número médio de unidade de trabalho foi de 18 dias-pessoa,
uma vez que os profissionais não estão familiarizados com a
linguagem em que o software foi desenvolvido;
6. Agora podemos calcular a quantidade de esforço estimada, sendo
38,5 (total de classes) x 18 dias = 693 dias por pessoa para
construção das classes;
7. Como a equipe de trabalho é composta por 5 pessoas, então a
distribuição de dias de trabalho por pessoa é calculando 693/5
resultando em, aproximadamente, 139 dias de trabalho por
pessoa.
8. Considerando um mês comercial com 22 dias úteis, leva-se
aproximadamente 6,3 (139/22) meses para concluir o projeto.
Resultando em, aproximadamente, 6 meses e 7 dias.
Aplicando a distribuição dos dias de trabalho por pessoa aos percentuais
11

de cada fase obtém-se as informações exibidas no Quadro 2 no qual se refere a
40% do tempo em planejamento do projeto, 20% desenvolvimento e 40% de
testes e manutenção.
Quadro 2 - Estimativa de dias de trabalho por pessoa para o desenvolvimento do projeto.
Etapa Modelo (%) Projeto (%) Cálculo Dias de trabalho
Planejamento 40 40 139*0,40 55 dias e 12 horas
Codificação 20 20 139*0,20 ~ 28 dias
Testes/Manutenção 40 40 139*0,40 55 dias e 12 horas
Resultado: 139 dias
Fonte: Autores.
2.2 Recursos do Projeto
Nesta seção são descritos os recursos utilizados para o desenvolvimento
do projeto. Os recursos descritos são: recursos humanos, recursos de software
e recursos de hardware.
2.2.1 Recursos Humanos
A equipe para o desenvolvimento é composta por 1 (um) gerente do
projeto, 2 (dois) analistas de sistemas, 1 (um) programador e 1 (um) analista de
testes de software.
2.2.2 Recursos de Software
Os softwares a serem utilizados no desenvolvimento deste projeto são:
1. StarUML, Bizagi e brModelo para o ambiente de modelagem dos
diagramas UML;
2. Google Docs para a escrita do plano de projeto compartilhado;
3. IDE para o desenvolvimento do sistema: Eclipse ou Netbeans;1
4. PostgreSQL para o gerenciamento do banco de dados;
1
Do inglês Integrated Development Environment ou Ambiente de Desenvolvimento Integrado, é
um programa de computador que reúne características para a implementação do software.
12

5. Ferramenta de controle de versão Subversion SVN.
2.2.3 Recursos de Hardware
As configurações necessárias a serem utilizadas para o desenvolvimento
do projeto nas 4 (quatro) estações de trabalho sugeridas estão descritas no
Quadro 3 abaixo.
Quadro 3 - Configurações para as estações de trabalho.
Produto Especificação
Processador Intel Core i5 Processor (4M Cache,
upto 3.10 GHz) ou superior
Disco rígido 500GB de armazenamento ou superior
Memória RAM 4GB ou superior
Monitor 8 monitores de 19 polegadas
Conexão à Internet Banda larga de no mínimo 15Mbps
Fonte: Autores.
3 ANÁLISE E GESTÃO DE RISCOS
A gestão de riscos é uma atividade que propicia a atuação da
organização de forma preventiva, suprimindo possíveis prejuízos, sejam eles de
natureza material ou humana. Ela viabiliza a elaboração de um ecossistema de
aperfeiçoamentos, não se limitando apenas ao ato de identificar e controlar as
prováveis ameaças. Para MORAES (2010), conforme a norma
australo-neozelandesa AS/NZS 4360/2004, a gestão de riscos é um processo
contínuo que deve ser aplicado nas seguintes situações:
● Necessidade de implementar controles não previstos inicialmente nos
projetos;
● Quando um novo trabalho for planejado;
● Quando forem realizadas mudanças significativas;
13

● Após a concorrência de incidente com potencial de perda ou dano
significativo;
● Periodicamente, no local de trabalho, envolvendo atividades rotineiras,
não rotineiras, emergenciais e futuras;
● Quando existirem regulamentos técnicos e legais e suas modificações.
Nesse sentido, é imprescindível o incentivo e a institucionalização de uma
política de gestão de riscos, para que eles possam ser melhor avaliados e
tratados. De acordo com (TEIXEIRA, 2015), isso não pode ser conduzido de
forma empírica e isolada, devendo haver uma sistematização. Além disso, é
necessário que existam indicadores que permitam monitorar e visualizar a
melhoria contínua.
3.1 Riscos do projeto
A seguir, são elencados no Quadro 4 os riscos identificados no projeto e o
possível impacto causado no mesmo, além de uma estimativa da sua
probabilidade de ocorrência. As informações foram provenientes de um
brainstorm entre os integrantes da equipe e em seguida realizada uma análise
circular. Também foi definido um ponto de corte, onde os itens acima do mesmo
entrarão no plano de redução, supervisão e gestão do risco.
Quadro 4 - Riscos do projeto.
Risco Descrição Categoria Probabilidade Impacto
001 Desistência do projeto Cliente 25% Catastrófico
002
Possibilidade de haver alguma falha no
banco de dados e perder dados
importantes. Negócio 10% Catastrófico
003
A equipe de criação não fará a
manutenção da ferramenta após sua
implantação. Equipe/Pessoas 65% Crítico
004
O cliente não acompanhar e participar
das reuniões e validações durante toda
a duração do projeto. Equipe/Pessoas 60% Crítico
005 Relevância para o público que utilizará Negócio 50% Crítico
14

o produto
006
O produto entregue efetua requisições
em demasia e/ou sobrecarrega a rede
ou sistema gerenciador de banco de
dados. Tecnologia 50% Crítico
007 Problemas na definição de requisitos Cliente 40% Crítico
008
Para uma boa satisfação do cliente, o
software precisará integrar-se a outras
ferramentas. Maturidade 35% Crítico
009
A equipe não tem muita experiência
com as tecnologias adotadas no
projeto. Equipe/Pessoas 65% Crítico
010
Mudanças de legislação quanto às
regras de negócio da aplicação Negócio 20% Crítico
PONTO DE CORTE
011
Limitação no conhecimento tecnológico
dos usuários finais Negócio 40% Marginal
012
Perceber durante a execução do
projeto que o mesmo é maior do que o
esperado. Tamanho 35% Marginal
013
Falta de um especialista na tecnologia
que será utilizada Tecnologia 35% Marginal
014
A equipe não pode dedicar-se
exclusivamente ao projeto Equipe/Pessoas 25% Marginal
3.2 Redução e Gestão do Risco
Após a identificação dos riscos do projeto é importante a elaboração de
estratégias de redução. Esses mecanismos são responsáveis por minimizar as
chances dos riscos em questão tornarem-se reais. Além disso, planos de
contingência podem auxiliar caso a ameaça em evidência transforme-se em
realidade. A seguir são mostradas as estratégias a serem adotadas para garantir
a Redução, Supervisão e Gestão dos Riscos (RSGR).
15

Quadro 5 - Risco 1 do projeto
Risco: 001 Probabilidade: 25% Impacto: Catastrófico
Descrição: Desistência do cliente do projeto.
Estratégia de Redução: Manter o que foi planejado para o projeto, visando
sempre a redução do custo e do tempo para manter o interesse do cliente
Plano de Contingência: Contratar um consultor especialista no assunto para
fazer o acompanhamento do projeto.
Pessoa responsável: Equipe de Planejamento.
Status: Concluído.
Risco: 002 Probabilidade: 10% Impacto: Catastrófico
Descrição: Possibilidade de haver alguma falha no banco de dados e perder
dados importantes.
Estratégia de Redução: Utilizar técnicas de espelhamento da base de dados.
Plano de Contingência: Fazer uso periódico de backups localmente. Usar a
redundância de dados. Efetuar backups na nuvem.
Pessoa responsável: Gerente de projetos, Analista de Sistemas e equipe de
Desenvolvimento.
Status: Concluído.
Risco: 003 Probabilidade: 65% Impacto: Crítico
Descrição: A equipe de criação não fará a manutenção da ferramenta após
sua implantação.
Estratégia de Redução: Criar artefatos de software bem documentados e
material de apoio para auxiliar o entendimento de uma nova equipe.
Plano de Contingência: Fornecer treinamento para a nova equipe a fim de
transmitir os conhecimentos adquiridos junto ao cliente e questões técnicas
adotadas no projeto.
Pessoa responsável: Equipe do Projeto.
Status: Concluído.
16

Descrição: O cliente não acompanhar e participar das reuniões e validações
durante toda a duração do projeto.
Estratégia de Redução: Conscientizar o cliente da importância de sua
participação no sucesso do projeto; flexibilizar datas, horários e formas de
realização das reuniões pensando na disponibilidade do cliente; solicitar
verificações periódicas do produto ao cliente.
Plano de Contingência: Procurar uma pessoa de confiança do cliente com
maior disponibilidade e que esteja apta a colaborar com a equipe do projeto;
estender os prazos para entrega incremental do projeto, de acordo com o
aumento das dificuldades em identificar as necessidades do cliente.
Pessoa responsável: Gerente de Projetos.
Status: Concluído.
Descrição: Relevância para o público que utilizará o produto.
Estratégia de Redução: Realizar pesquisas periódicas com o público para
verificar o seu grau de satisfação e reunir sugestões de melhorias no sistema.
Plano de Contingência: Entrar em contato com a equipe de Marketing da
organização para traçar um plano de ações e medidas que aumentem a
relevância do produto para o público-alvo.
Pessoa responsável: Analista de Sistemas
Status: Concluído.
Descrição: O produto entregue efetua requisições em demasia e/ou
sobrecarrega a rede ou sistema gerenciador de banco de dados.
Estratégia de Redução: Construir o sistema visando o consumo mínimo de
recursos de rede; escolher um servidor Web compatível com as necessidades
17

identificadas.
Plano de Contingência: Refatoração do código para reduzir o número de
requisições realizadas e consumo de banda; realizar upgrade do servidor para
adequar-se às necessidades.
Pessoa responsável: Equipe de Desenvolvimento.
Status: Concluído.
Descrição: Problemas na definição de requisitos.
Estratégia de Redução: Criar um processo de gerenciamento de mudanças de
requisitos; Enfatizar e realizar minuciosamente o processo de engenharia de
requisitos; Utilizar metodologias que permitam uma participação colaborativa e
próxima dos stakeholders durante as atividades de levantamento, análise e
validação dos requisitos.
Plano de Contingência: Realizar reuniões com os stakeholders e aplicar o
processo de gerenciamento de mudanças para identificar e registrar as
necessidades de alterações, realizar uma análise de impacto e posteriormente
implementar a mudança.
Pessoa responsável: Analista de Sistemas.
Status: Concluído.
Descrição: Para uma boa satisfação do cliente, o software precisará
integrar-se a outras ferramentas.
Estratégia de Redução: Encontrar algum tipo de documentação e
padronização dos softwares aos quais deseja-se efetuar a integração; utilizar a
ferramenta em questão para melhor entendê-la.
Plano de Contingência: Realizar procedimentos de engenharia reversa para
compreender o outro software; entrar em contato com os desenvolvedores da
aplicação para sanar dúvidas.
18

Status: Concluído.
Descrição: A equipe não tem muita experiência com as tecnologias adotadas
no projeto.
Estratégia de Redução: Fornecer treinamento e capacitação para a equipe
antes do início do projeto; disponibilizar manuais, vídeos e outros materiais que
possam prover um entendimento emergencial; contratar pessoas que tenham
maior familiaridade com as tecnologias a serem utilizadas.
Plano de Contingência: Negociar os prazos de entrega das funcionalidades do
produto em desenvolvimento e tentar, caso seja possível, terminar o projeto
utilizando uma tecnologia já conhecida pela equipe de desenvolvimento.
Status: Concluído.
Descrição: Mudanças de legislação quanto às regras de negócio da aplicação.
Estratégia de Redução: Orientar aos desenvolvedores que implementem os
dados vinculados à legislação como um parâmetro no banco de dados, para
que mudanças que venham a ocorrer possam ser feitas sem a necessidade de
modificação do código-fonte da aplicação.
Plano de Contingência: Avaliar, junto à equipe de desenvolvimento, todos os
pontos em que é necessária a intervenção no código-fonte e modificá-las
imediatamente.
Pessoa responsável: Analista de Sistema, Equipe de Desenvolvimento
Status: Concluído.
Risco: 011 Probabilidade: 40% Impacto: Marginal
Descrição: Limitação no conhecimento tecnológico dos usuários finais.
19

Estratégia de Redução: Fornecer treinamento e capacitação para a equipe
durante e após a conclusão do projeto; disponibilizar manuais, vídeos e outros
materiais que possam prover um entendimento emergencial; contratar pessoas
que tenham maior familiaridade com as tecnologias a serem utilizadas.
fazer o treinamento.
Status: Concluído.
Descrição: Perceber durante a execução do projeto que o mesmo é maior do
que o esperado.
Estratégia de Redução: Verificar o escopo do projeto a cada reunião. Definir
quais os módulos-chave e quais as funcionalidades que podem ser postergadas
caso seja necessário realizar algum corte no escopo do projeto.
Plano de Contingência: Negociar valores com o cliente; propor entregas
incrementais do software.
Status: Concluído.
Descrição: Falta de um especialista na tecnologia que será utilizada.
Estratégia de Redução: Tentar trabalhar com tecnologias que já foram
utilizadas pela equipe de desenvolvimento em projetos anteriores caso o projeto
em questão apresente uma grande complexidade. Utilizar novas tecnologias
apenas em projetos menores. .
fazer o acompanhamento do projeto.
Status: Concluído.
20

Descrição: A equipe não pode dedicar-se exclusivamente ao projeto.
Estratégia de Redução: Alocar uma parte da equipe para dar maior enfoque
ao projeto e rotacionar seus membros; Planejar módulos do projeto que possam
ser terceirizados.
Plano de Contingência: Parar outros projetos e atividades em andamento de
menor prioridade; Custear horas extras e motivar financeiramente a equipe para
que se dedique ao projeto.
Status: Concluído.
4 PLANEJAMENTO TEMPORAL
4.1 Conjunto de Tarefas do Projeto
O projeto +Paciente baseia-se no modelo cascata de desenvolvimento,
no qual as atividades ocorrem de maneira sequencial, com uma atividade
começando somente após o fim da atividade anterior. Porém, sabendo de
algumas das deficiências de tal modelo, e aplicando conhecimentos de gestão
de projetos da equipe envolvida, diversas adaptações foram realizadas. A ideia é
tornar o processo mais dinâmico, em especial com o uso de processos e
princípios advindos de métodos ágeis. A seguir, tem-se um apanhado sobre
cada etapa do processo e, para as atividades mais complexas, uma subdivisão
de tarefas a serem executadas:
1. Abertura do Projeto - Em um projeto como o +Paciente, tudo se inicia
com o contato de algum Stakeholder, no qual o mesmo discorre sobre a
necessidade de resolver um determinado problema do seu dia-a-dia. Em
seguida, algumas reuniões são marcadas com a equipe e o cliente para que
todos entrem num consenso sobre o que deve ser feito. Obviamente, durante as
21

primeiras reuniões, diversos detalhes ainda não estão claros. Por isso, nesse
momento inicial, não há a necessidade da criação de um plano de projeto. Após
as primeiras reuniões, um documento de abertura de projeto é criado e assinado
pelos envolvidos. Neste momento, ainda não se tem detalhes do custo e
duração do projeto, mas uma página Wiki deve ser criada e acoplada ao
Redmine, apenas para controle inicial.
2. Definição do Escopo - A definição do escopo deve ocorrer o quanto
antes. É crucial que a equipe saiba rapidamente o que de fato precisa ser feito
no projeto, e o que não deve ser entregue em tal projeto.
3. Reuniões com Cliente - Reuniões ocorrerão durante todo o projeto,
porém, durante as etapas iniciais é interessante que aconteçam com maior
frequência. É importante utilizar essas primeiras reuniões para definir de forma
mais precisa o escopo do projeto.
4. Levantamento de Requisitos - Essa etapa se inicia junto com o
processo anterior. Porém, depende parcialmente do mesmo, uma vez que parte
dos requisitos pode surgir desde a primeira reunião, mas, ao mesmo tempo,
detalhes que podem parecer requisitos importantes a priori podem fugir do
escopo e acabar descartados com o tempo. Documentação extensa demais é
desaconselhada no primeiro momento, e técnicas como o uso de histórias de
usuário e até esboços à mão podem ajudar as partes envolvidas a elucidar os
principais requisitos, ainda sem detalhes de tecnologia a ser utilizada,
ferramentas e outros. A ideia aqui é criar artefatos simples, mas que transmitam
bem a necessidade do cliente para toda a equipe, independente da função
exercida por cada membro. Essa etapa vai se prolongar até parte da análise de
requisitos, indo contra modelos mais clássicos, e isso se deve pelo fato de que é
muito comum a mudança de requisitos e até de escopo ainda no começo do
projeto. Revisamos, então, o que foi elicitado nas primeiras semanas durante a
fase de Análise.
22

5. Refinamento de Requisitos - Durante todo o processo de definição
dos requisitos, há uma tarefa herdada das metodologias ágeis chamada
Grooming (geralmente traduzida como refinamento). É durante essa tarefa que
os requisitos são revisitados por membros da equipe para que se tornem mais
claros, seja detalhando mais os critérios de aceite, modificando a linguagem
utilizada ou até criando algum artefato UML que pareça necessário. Essa etapa
depende muito da sensibilidade de cada membro da equipe, e não é essencial,
mas altamente recomendada.
6. Análise de Requisitos - Aqui, detalhes sobre os modelos de dados,
estrutura básica do software e um maior aprofundamento dos requisitos
começam a aparecer, ainda sem uma arquitetura bem definida. No entanto,
surge uma necessidade de documentar melhor o projeto, por isso a atividade
seguinte acontece praticamente em paralelo. Durante a análise e levantamento
de requisitos, é fundamental que a Wiki seja atualizada. Com isso, tem-se um
artefato que pode ser acompanhado antes do surgimento do plano de projeto e
com uma visão mais prática do que já foi identificado.
7. Criação do Plano de Projeto - O plano de projeto é um documento
comum para uma série de Modelos, e o importante aqui é gerar algo legível para
a equipe, rastreável para o gestor e que possa ser verificado e até modificado ao
longo do projeto, se necessário. Esse documento deve trazer detalhes sobre o
escopo, objetivo, equipe envolvida, riscos possíveis e planejamento temporal,
dentre outros possíveis tópicos. Aqui, é interessante notar que parte dessa
informação ainda não existe, por isso o plano deve ser revisado em momentos
futuros. Além disso, é essencial que a equipe desenvolva algum tato para
remover campos e acrescentar outros, de acordo com as características de cada
projeto. A versão inicial pode ser mantida na própria Wiki mas, por questão de
praticidade, é interessante incluir este documento nas ferramentas de controle
de versão em momentos futuros.
23

8. Projeto de Arquitetura - Durante essa tarefa, é natural que uma série
de questões já tenham sido discutidas entre a equipe, como: a forma com os
componentes do sistema vão se relacionar, a forma como os dados persistidos
serão mantidos, e outros detalhes de implementação. É aqui onde esses
detalhes devem ser descritos e decididos. Justamente por isso que para que
essa tarefa seja concluída, a equipe precisa ter a versão inicial do Plano de
Projeto, que agora será atualizada, e também que a análise de riscos tenha sido
feita, uma vez que podem surgir riscos que exijam uma mudança no projeto para
minimizar a chance de fracasso do mesmo.
9. Análise e Gestão de Risco - Definir o máximo de riscos possíveis e
criar um plano de gestão para tais riscos, seja por meio de mitigação ou até
remoção total. Muitas organizações têm projetos fracassados justamente por
não darem a devida atenção a tais tarefas. Outra vantagem de registrar tal
análise é manter um histórico para projetos futuros, que gera um certo
amadurecimento da organização. O documento relativo a essa tarefa pode ser
acoplado como parte do plano de projeto, ou se a equipe preferir, mantido como
documento a parte. O importante é garantir a rastreabilidade entre os
documentos, no caso de existir mais de um, e evitar retrabalho.
10. Codificação - Uma vez que as etapas anteriores tenham sido bem
exploradas, a codificação acaba se tornando uma tarefa sem muitos problemas.
Ainda assim, é importante ter alguns cuidados. A ferramenta de controle de
versão deverá ser utilizada diariamente pela equipe.
11. Programação em Par - Para tornar o processo de desenvolvimento
mais preciso, é recomendado que a equipe faça uso de Programação em Par
em determinados momentos. Essa prática, vinda do Extreme Programming(XP),
ajuda a evitar erros comuns durante a fase de codificação, pois garante que o
código esteja sendo revisado com frequência à medida que o mesmo é
produzido. Isso reduz a carga de testes necessários nas etapas posteriores e
aumenta a chance de sucesso do projeto. Portanto, a equipe do +Paciente
24

definiu a prática como parte de seu processo na criação das funcionalidades
mais críticas.
12. Ajustes no Plano de Projeto - Ajustes serão efetuados no plano de
projeto durante toda a duração do mesmo, porém com maior intensidade
durante o final da etapa de Projeto de Arquitetura.
13. Testes de Unidade e Integração - Alguns dos programadores farão
uso de Test Driven Development (TDD), que é mais uma prática incorporada do
XP ao +Paciente, novamente com intuito de reduzir a carga de testes e
aumentar a qualidade do produto. É importante ressaltar que o TDD ataca
somente os testes de níveis mais atômicos, como os testes de unidade.Então, a
utilização de tal prática não elimina testes mais complexos e robustos do projeto.
Grande parte dos testes, principalmente os de unidade e UI serão mantidos nos
próprios ambientes de desenvolvimento e espelhados juntos com o código na
ferramenta de controle de versão.
14. Testes de Aceitação e Integração - Ao contrário do que é visto em
modelos clássicos como o Cascata, a equipe do projeto +Paciente definiu que
parte dos testes ocorreriam durante a etapa de Codificação. Isso torna o
processo um pouco mais lento, mas garante ainda mais a qualidade tanto do
processo geral quanto do produto final. Uma vez que alguns tipos de teste, em
especial testes de sistema e de User Interface(UI) custam bastante e exigem
maior dedicação da equipe, esses testes devem ser preparados de forma
isolada e executados após toda a codificação, incluindo possíveis ajustes nas
funcionalidades como parte de seu tempo de aplicação, já que não há uma
equipe dedicada a testes nesse projeto. Os testes de aceitação também
ocorrerão em paralelo às atividade de codificação, além disso integração
contínua será efetuada ao longo do projeto.
25

15. Revisão Final do Plano de Projeto - Ao final das etapas de
codificação e testes, a última revisão do Plano de Projeto deverá ser efetuada,
após isso apenas pequenos ajustes devem ocorrer em tal documento.
16. Testes de Sistema - A última etapa de testes deve incluir
obrigatoriamente Testes de Sistema. Tais testes são essenciais para garantir um
bom funcionamento do sistema uma vez implantado. Além disso demais testes
podem ser efetuados, a depender da necessidade da equipe.
17. Gestão de Configuração - Apesar de inserida após os testes e de
haver uma certa dependência dos mesmos, a gestão de configuração é uma
atividade que deve ocorrer diariamente, em pequenas parcelas, pois ela melhora
o gerenciamento de tudo o que vai se entregue e de possíveis mudanças no
projeto. Sendo assim, acumular todo o trabalho para o final do projeto não se
adequa às necessidades da equipe do +Paciente. Aqui, o controle de versão
com uso de Git e demais ferramentas de gerência de projeto se mostram ainda
mais necessárias.
18. Criação do Manual do Usuário - A equipe deve se preocupar em
criar um Manual de Usuário, de forma descritiva e com uma linguagem o mais
simples possível. O guia servirá de apoio durante os primeiros contatos dos
usuários com o novo sistema, e também para possíveis usuários que surjam
após a implantação, como novos colaboradores contratados.
19. Treinamento com Usuário- Em seguida a equipe deverá começar a
implantação de fato, e realizar um treinamento com os principais usuários
disponíveis no período, para que a base de todo o sistema já seja conhecida do
maior número possível de usuários antes do mesmo entrar de fato em
funcionamento.
20. Implantação - Por fim, o sistema é inserido e efetivado no local
desejado, caracterizando o fim da implantação. Deve ser criado um documento
26

que comprove a entrega do que foi planejado, com assinatura dos envolvidos
presente, inclusive dos membros da equipe.
4.2 Diagrama de Gantt
As atividades ao longo de todo o processo podem ser observadas no
Diagrama de Gantt de forma temporal. Sendo uma importante ferramenta de
gestão para a equipe, uma vez que facilita a identificação do estado atual do
processo. Exibindo atrasos e ajustes com relação ao esperado de forma visual.
A imagem que representa o Diagrama de Gantt deste projeto se encontra no
Apêndice I.
5 ORGANIZAÇÃO DO PESSOAL
Nesta seção é apresentado a forma de organização da equipe ao longo
do desenvolvimento do projeto.
5.1 Estrutura da equipe
O Quadro 19 mostra a composição da equipe e os papéis
desempenhados por cada membro no desenvolvimento do +Paciente.
Quadro 19 - Estrutura da equipe
Nome Função Descrição
Ícaro Prado Gestor do Projeto O gerente de projetos exerce a
função de planejar e controlar a
execução dos projetos com o
intuito de conduzir melhor a
equipe.
Antonio Martins
e Allan Silva
Analista de Sistema O analista de sistema tem a função
de projetar o sistema. Atua com
análise e projeto de sistemas,
levantamento de requisitos, regras
de negócio, mapeamento de
processos e modelagem de dados.
Ele atuará com padrões de
qualidade das rotinas e processos
e impacto das alterações.
27

Lucas Cruz Desenvolvedor O desenvolvedor exerce a função
de codificar ou prestar manutenção
em rotinas de um sistema
específico.
Diego Rodrigues Analista de Testes O testador exerce a função de
verificação do funcionamento do
software, localizando e registrando
as falhas e como elas acontecem
repassando-as para a equipe de
desenvolvimento.
Fonte: Autores
5.2 Mecanismos de comunicação
Os mecanismos de comunicação da equipe e esquemas de monitorização do
avanço do projeto foram as ferramentas descritas no Quadro 20.
Quadro 20 - Mecanismos de comunicação
Ferramenta Descrição
Whatsapp Ferramenta de chat via dispositivos mobile
e/ou navegadores web.
Trello Ferramenta para controle do progresso
baseado em quadros Kanban.
Google Drive Mostrou-se uma ferramenta colaborativa
poderosa aproximando os membros da equipe
na elaboração de documentos e papéis do
trabalho.
Fonte: Autores
5.3 Uso do Edu-blog como ferramenta de apoio
Além das ferramentas citadas acima, para o desenvolvimento deste plano
de projeto foi necessário o apoio dos Edu-Blogs, serviço do Google chamado de
28

Blogger, onde foi fornecido pela disciplina de Gerência de Projetos criado pelo
Prof.º Dr.º Rogério Patrício Chagas do Nascimento.
Esta ferramenta proporcionou um aprendizado descentralizado e
uniforme, onde todos os assuntos disponibilizados foram expostos de forma
clara e flexível. Desta forma, entende que esta ferramenta auxiliou no processo
de incentivo a busca de novidades e assuntos tecnológicos.
5.4 Ferramentas de Gestão do Projeto
O gerenciamento do +Paciente exige uma ferramenta para o controle
das tarefas e reuniões, sendo assim, o Redmine é adequado ao projeto, uma
vez que permite personalização suficiente para adição de quadros Kanban e
outras adaptações para métodos ágeis que foram usados como base. Além
disso, páginas Wiki associadas ao projeto também serão criadas e mantidas
pela equipe.
Outra ferramenta importante foi o Smartsheet, que permite facilitar parte
da gestão com uso de gráficos como o popular Gráfico de Gantt, utilizado para
estimar as datas de início, fim, e o responsável por cada tarefa dentro do projeto
de uma forma visual e amigável.
6 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A
QUALIDADE DO PRODUTO DE SOFTWARE
Para garantir a qualidade do software desenvolvido neste projeto, foram
tomadas medidas que tornaram possível o controle de qualidade em mais de
uma dimensão do termo “qualidade”: qualidade quanto ao atendimento das
expectativas do usuário, e qualidade quanto ao grau de corretude do código
(ausência de bugs e uso de padrões de desenvolvimento, por exemplo).
Apesar do desenvolvimento em na metodologia Cascata, foram utilizados
ciclos de desenvolvimento incrementais durante a codificação, em que o produto
29

finalizado naquele ciclo era apresentado ao cliente para ser validado e ter suas
funcionalidades avaliadas.
Com o desenvolvimento incremental, aliado ao artifício de prototipação de
telas, foi possível a verificação do grau de satisfação do cliente com o produto
desenvolvido em diferentes estágios de completude, garantindo que o
desenvolvimento seguisse o caminho certo quanto o atendimento dos requisitos.
Quanto à qualidade de código, foi utilizada a ferramenta SonarQube, da
SonarSource. Com ela, foi possível verificar a existência de bugs, code smells,
vulnerabilidades e duplicações no código fonte.
REFERÊNCIAS
LORENZ M.; KIDD, J. Object-oriented software metrics: a practical guide.
[S.l.]: Prentice-Hall, Inc., 1994.
HOSPITAL UNIVERSITÁRIO DE SERGIPE HU-UFS - EBSERH, Disponível em:
<http://www.ebserh.gov.br/web/hu-ufs>. Acesso em 28 de setembro de 2017.
MORAES, G. Sistemas de gestão de riscos, princípios e diretrizes iso
31.000/2009, comentada e ilustrada-. Editora GVC, v.1, 2010. Citado na página
18.
PRESSMAN, Roger; MAXIM, Bruce. Engenharia de Software: Uma
Abordagem Profissional. 8ª Edição. Editora McGraw Hill Brasil, 2016.
SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. Editora Person
Education, 2007.
REDMINE, Disponível em: <https://www.redmine.org/>. Acesso em 28 de
novembro de 2018.
SMARTSHEET, Dispinível em: <https://www.smartsheet.com/> . Acesso em
12/02/2019.
30

TEIXEIRA, A. S. O que é Gestão de Risco? 2015. Disponível em
<http//:www.blogdaqualidade.com.br/o-que-e-gestao-de-risco/>. Acesso em: 20
jan. 2018. Citado na página 18.
31

APÊNDICE 1 - DIAGRAMA DE GANTT DO PLANEJAMENTO TEMPORAL
32

Plano de projeto

Mais conteúdo relacionado

Mais procurados

Semelhante a Plano de projeto

Plano de projeto