Plano de Projeto de Software - SIUR

UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Sistema de Informação da Unidade de Reabilitação – SIUR
Plano de Projeto de Software
Claudson Bispo Martins Santos
Edgar Vieira Lima Neto
Guilherme Boroni Pereira
Departamento de Computação/UFS
São Cristóvão – Sergipe
2018

UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Claudson Bispo Martins Santos
Edgar Vieira Lima Neto
Guilherme Boroni Pereira
Sistema de Informação da Unidade de Reabilitação – SIUR
Trabalho apresentado ao Prof. Dr. Rogério Patrício
Chagas do Nascimento como nota parcial da disci-
plina Gerência de Projetos do curso de graduação em
Sistemas de Informaçãoda Universidade Federal de
Sergipe(UFS).
Orientador(a): Prof. Dr. Rogério Patrício Chagas do
Nascimento
São Cristóvão – Sergipe
2018

Lista de ilustrações
Figura 1 – Diagrama de Caso de Uso. . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Figura 2 – Diagrama de Pacotes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Figura 3 – Diagrama de Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figura 4 – Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Lista de tabelas
Tabela 1 – Atores da aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Tabela 2 – Classiﬁcação dos multiplicadores . . . . . . . . . . . . . . . . . . . . . . . 16
Tabela 3 – Estimação do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Tabela 4 – Riscos do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Tabela 5 – Alocação de funções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Sumário
1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Requisitos Funcionais Identiﬁcados . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Requisitos Não-Funcionais Identiﬁcados . . . . . . . . . . . . . . . . . . . . . 13
1.2.1 Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.2 Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3 Restrições Existentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 Estimações do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1 Técnicas de Estimação e Resultados . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 Técnica de Estimação . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Recursos do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.1 Recursos de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.2 Recursos de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.3 Recursos Humanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Análise e Gestão de Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1 Riscos do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Redução e Gestão dos Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4 Planejamento Temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1 Conjunto de Tarefas do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3 Comparação com a realidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5 Organização do Pessoal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1 Estrutura da Equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2 Mecanismos de Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3 Uso do Edu-blog como Ferramenta de Apoio . . . . . . . . . . . . . . . . . . 27
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5
1Introdução
O HU/UFS é prestador de serviços para o Sistema Único de Saúde (SUS), e não realiza
atendimentos particulares ou a usuários de planos de saúde. A unidade possui referência em
atendimentos de média e alta complexidade, tanto em relação ao ambulatório quanto aos exames
complementares, diagnóstico e internação. O principal acesso ao atendimento sistemático no
Hospital é através do Serviço Ambulatorial, regulado pela Secretaria Municipal de Saúde de
Aracaju (SE) através do NUCAAR.
O Hospital possui diversas unidades de atendimento que prestam serviços para deter-
minadas especialidades. O SIUR contemplará todos os setores acobertados pela Unidade de
Reabilitação, responsável pelo serviço de fisioterapia. Atualmente os setores que possuem essa
unidade são: Unidades de Terapia Intensiva (UTI), Enfermarias e Ambulatórios.
A Unidade de Reabilitação está relacionada com os principais e mais movimentados
setores do HU/UFS, o que significa dizer que sempre haverá uma elevada demanda de pacientes
por esse serviço. Para cada atendimento é relacionada uma ficha com os dados do paciente que é
preenchida pelo profissional em saúde e permite avaliar o estado e evolução do paciente durante
o tratamento. Esse controle manuscrito é o principal problema para o HU/UFS já que acaba
causando um enorme prejuízo de tempo para cada atendimento e não permite um aproveitamento
maior dos dados registrados.
Com a implantação do SIUR haverá um impacto extremamente positivo para os se-
tores com Unidade de Reabilitação, possibilitando um atendimento mais rápido e eficiente e
solucionando o problema do HU/UFS com o tratamento de reabilitação.
1.1 Requisitos Funcionais Identificados
A seguir são apresentados os atores da aplicação. Cada ator representa um papel particular
de usuário da aplicação. Porém, além de representar pessoas, os atores também podem ser

Capítulo 1. Introdução 6
dispositivos de hardware ou até outras aplicações que devam trocar informações com a aplicação
a ser desenvolvida. A tabela a seguir descreve brevemente cada ator da aplicação.
Tabela 1 – Atores da aplicação.
Ator Descrição
Usuário Toda pessoa que acessa o sistema por meio de login e senha. Serão
basicamente os fisioterapeutas e residentes.
Administrador Um subconjunto de usuários (especialização) com maiores privilégios
dentro do sistema, comumente o chefe da unidade de reabilitação.
Pacientes São as pessoas atendidas no HU/UFS pelos fisioterapeutas da unidade
de reabilitação.
AGHU Sistema de gerenciamento do HU, de onde poderão ser lidos dados de
pacientes já atendidos por outros setores do hospital.
O diagrama de caso de uso abaixo auxilia na compreensão dos requisitos identificados e
descritos mais adiante. Já os Diagramas de Pacote e de Classes permitem o entendimento geral
das classes do sistema.

Figura 1 – Diagrama de Caso de Uso.

Figura 2 – Diagrama de Pacotes.

Capítulo1.Introdução9
Figura 3 – Diagrama de Classes.

Os requisitos descritos a seguir possuem o intuito de prover funcionalidades que visam o
gerenciamento dos usuários do SIUR.
[RF001] Cadastrar Usuários
Prioridade: Essencial Importante Desejável
Ator(es): Administrador
Requisitos Associados: RF002
Objetivo: Permite aos administradores a criação de novos utilizadores
do SIUR, os quais devem receber um perfil de acesso.
[RF002] Manter Perfis de Acesso
Requisitos Associados: Nenhum
Objetivo: Permite aos administradores a manutenção de diferentes per-
fis de acesso ao sistema, bem como as permissões associadas
a cada um deles.
[RF003] Alterar Dados da Conta
Ator(es): Usuário e Administrador
Objetivo: Permite aos atores alterarem informações pessoais relaciona-
das às suas contas.
[RF004] Recuperar Senha
Objetivo: Permite aos atores reaverem o acesso às suas contas em caso
de esquecimento dos dados de acesso.
[RF005] Efetuar Login
Objetivo: Libera o acesso ao SIUR somente após fornecido login e
senha pelos atores, os quais terão acesso apenas aos recursos
aos quais possuem permissão.

Os requisitos seguintes possuem o intuito de prover funcionalidades que visam o geren-
ciamento dos pacientes do SIUR.
[RF006] Manter Pacientes
Ator(es): Usuário, Administrador e Paciente
Objetivo: Permite aos usuários e administradores a criação, edição,
remoção e visualização de pacientes no SIUR, bem como
a manutenção de dados associados ao mesmo, tais como
contatos de parentes e patologias que ele possui.
[RF007] Importar Pacientes
Objetivo: Permite aos usuários e administradores que no momento
de criação de um novo paciente possam importar os dados
associados ao mesmo da base de dados do AGHU.
[RF008] Manter Tratamentos
Objetivo: Permite aos usuários e administradores a manutenção dos
cadastros dos tratamentos dos pacientes.
[RF009] Manter Avaliações
Requisitos Associados: RF008 e RF010
Objetivo: Permite que os usuários e administradores adicionem, alte-
rem, visualizem e removam as informações coletadas durante
as avaliações dos pacientes.

Os requisitos descritos adiante possuem o intuito de prover funcionalidades que visam o
gerenciamento das fichas de avaliação do SIUR.
[RF010] Manter Fichas
Objetivo: Permite aos atores a criação, alteração, visualização e remo-
ção de fichas de avaliação dos pacientes.
[RF011] Manter Respostas
Requisitos Associados: RF010 e RF009
Objetivo: Permite aos usuários e administradores a criação, alteração,
visualização e remoção das respostas dos pacientes referen-
tes a uma ficha de avaliação.
[RF012] Manter Classificações
Objetivo: Permite aos usuários e administradores a criação, alteração,
visualização e remoção das informações da Classificação
Internacional de Funcionalidade, Incapacidade e Saúde.

Por fim, são descritos os requisitos com o intuito de prover funcionalidades que visam
fornecer aos atores informações relacionadas ao sistema como um todo.
[RF013] Visualizar Estatísticas
Objetivo: Permite aos atores a visualização na dashboard de alguns
indicadores referentes às informações armazenadas no sis-
tema, tais como quantidade de avaliações realizadas, número
de pacientes em tratamento atualmente, tempo médio de
duração dos tratamentos, dentre outros.
[RF014] Gerar Relatórios
Objetivo: Permite ao ator gerar relatórios a partir de dados armazena-
dos no sistema, tais como a lista de pacientes atendidos em
um determinado período, diagnósticos tratados com mais
frequência, dentre outros.
1.2 Requisitos Não-Funcionais Identificados
Quaisquer requisitos relacionados com a performance (tempos de execução, sincroniza-
ção com equipamentos ligados ao software) do sistema e aspectos especiais de comportamento
(características da interface, etc.).
1.2.1 Usabilidade
• A interface do sistema deverá ser responsiva, ou seja, mudar a sua aparência e disposição
dos conteúdos com base no tamanho de tela do dispositivo pelo qual está sendo acessado,
visando proporcionar uma melhor experiência de navegação para o usuário;
• Visando proporcionar aos usuários do SIUR uma operação do sistema mais eficiente, as
interfaces devem permitir, sempre que possível, a entrada de dados por meio de seleção ao
invés da digitação de campos;
1.2.2 Segurança
• Os acessos ao SIUR devem ser controlados mediante autenticação dos usuários por meio
de login e senha;

• Por padrão, devem existir os perﬁs de acesso de usuário e administrador. Onde os ad-
ministradores terão permissão para realizar todas as operações do sistema e os usuários
terão permissão para efetuar login, recuperar senha, alterar dados da conta, manter ﬁchas,
manter pacientes, importar pacientes, manter avaliações e manter tratamentos.
1.3 Restrições Existentes
O versionamento do SIUR deverá seguir os padrões estabelecidos pelo Versionamento
Semântico 2.0.0. Além disso, os códigos desenvolvidos devem seguir os padrões estabelecidos
pelo Google Java Style Guide, com a utilização de blocos de indentação de 4 espaços.
O sistema deverá ser construído utilizando a linguagem Java para realização do processa-
mento no lado do servidor (backend) e JavaScript para as interações no lado do cliente (frontend).
O SGBD para persistência dos dados deve ser o PostgreSQL a partir da versão 9. O servidor de
execução da aplicação deve ser o Apache Tomcat v7.

15
2Estimações do Projeto
Medição é um processo imprescindível para o controle e avaliação de projetos em todas
as áreas, na engenharia de software esse processo também não é diferente (PRESSMAN, 2005),
principalmente com a crescente necessidade de melhoria e controle constante dos projetos de
software. Segundo Park, Goethert e Florac (1996), as quatro razões 27 para medir software são
caracterizar, avaliar, prever e melhorar. Conforme Fenton e Neil (1999), o foco da medição é
fornecer informações para apoiar gerencialmente a tomada de decisão durante o processo de
desenvolvimento, possibilitar a melhoria contínua, auxiliar na estimativa, controle de qualidade
e avaliação do software (PRESSMAN, 2005).
2.1 Técnicas de Estimação e Resultados
Nesta seção são apresentadas as técnicas de estimação utilizadas e os resultados proveni-
entes.
2.1.1 Técnica de Estimação
As estimativas que serviram de base ao desenvolvimento do projeto foram calculadas de
acordo com as métricas de Lorenz e Kidd. Essas métricas foram escolhidas por se adequarem
bem ao desenvolvimento de softwares construídos de acordo com o paradigma de orientação a
objetos, como é o caso deste software.
1. Deﬁnir o número de classes chave;
2. Encontrar o número de classes de suporte, que para isso temos que classiﬁcar o tipo de
interface do produto e desenvolver um multiplicador para as classes de suporte;
3. Multiplicar a quantidade de classes-chave pelo multiplicador para obter uma estimativa do
número de classes de suporte;

Capítulo 2. Estimações do Projeto 16
4. Logo após, calcula-se a quantidade total de classes, somando o número de Classes-Chave
com o número de classes de suporte;
5. Multiplicar a quantidade total de classes pelo "número médio de unidades de trabalho
(pessoas-dias)"; (A sugestão do criador é que para cada classe sejam escolhidos entre 15 e
20 dias/pessoa);
6. Determinar a quantidade de esforço estimada;
7. Calcular o tempo previsto para elaboração do projeto.
Tabela 2 – Classificação dos multiplicadores.
Interface Multiplicador
Não Gráfica 2
Baseada em Texto 2.225
GUI 2.5
GUI Complexa 3
2.1.2 Resultados
1. O número de classes chave é 5 (Usuário, Paciente, Tratamento, Avaliação, Ficha);
2. Pela natureza do projeto as classes possuem como fator multiplicador 2.5;
3. O número de classes de suporte estimado é 12,5;
4. O total de classes estimadas projetadas para o sistema é de aproximadamente 17,5;
5. Como os profissionais não estão familiarizados com a ferramenta o número médio de
unidades de trabalho será 17 dias-pessoa por classe;
6. A quantidade de esforço estimada é de 297,5 dias (17,5 x 17);
7. Como a equipe é composta de 3 desenvolvedores, a distribuição será de 99,16 dias de
trabalho para cada pessoa.
Aplicando a distribuição dos dias de trabalho por pessoa, temos o seguinte resultado:
Tabela 3 – Estimação do projeto.
Etapa Projeto (%) Dias de Trabalho
Planejamento 40 39,6
Codificação 20 19,96
Testes 40 39,6
Total 100 99,16

Capítulo 2. Estimações do Projeto 17
2.2 Recursos do Projeto
Esta seção discorre a respeito dos recursos que serão utilizados no durante o projeto,
sejam eles humanos ou tecnológicos.
2.2.1 Recursos de Software
• Apache Tomcat v7 ou superior;
• PostgreSQL v9 ou superior;
• SVN;
• RedMine;
• IDE para JAVA e JSP (Recomenda-se o uso do Eclipse ou Spring Tool Suite versão maior
ou igual a 3.8.4);
• Navegador Google Chrome.
2.2.2 Recursos de Hardware
A seguir são listados os requisitos mínimos referentes ao hardware da aplicação:
• Processador de 1GHz ou superior;
• Memória de 2GB ou superior;
• Periféricos básicos.
2.2.3 Recursos Humanos
• Para manutenção do sistema,o pessoal de suporte do SIUR deve estar ciente das funci-
onalidades do sistema descritas em todas as documentações e manuais e devem possuir
habilidade de programação em Java para Web.
• Para utilização do sistema, os usuários devem receber o treinamento adequado, bem como
ler os manuais de uso fornecidos.

18
3Aná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-neozelandeza AS/NZS 4360/2004, a gestão de riscos é um processo contínuo que deve
ser aplicado nas seguintes situações:
a. Necessidade de implementar controles não previsto inicialmente nos projetos;
b. Quando um novo trabalho for planejado;
c. Quando forem realizadas mudanças significativas;
d. Após a concorrência de incidente com potencial de perda ou dano significativo;
e. Periodicamente, no local de trabalho, envolvendo atividades rotineiras, não rotineiras,
emergenciais e futuras;
f. 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. Ainda, é necessário que hajam indicadores que permitam monitorar e
visualizar a melhoria contínua.

Capítulo 3. Análise e Gestão de Riscos 19
3.1 Riscos do Projeto
A seguir são elencados 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.
Tabela 4 – Riscos do projeto.
Risco Descrição Impacto Probabilidade
001 A equipe não tem muita experiência com as tec-
nologias adotadas no projeto
critico 45%
002 Levantamento de requisitos falhos critico 30%
003 O cliente não acompanhar e participar das reu-
niões e validações durante toda a duração do
projeto
critico 20%
004 Perceber durante a execução do projeto que o
mesmo é maior do que o esperado
critico 20%
005 O produto entregue efetua requisições em dema-
sia e/ou sobrecarrega a rede ou sistema gerencia-
dor de banco de dados
crítico 15%
006 A equipe de criação não fará a manutenção da
ferramenta após sua implantação
moderado 90%
007 A equipe não pode se dedicar exclusivamente ao
projeto
moderado 80%
008 Para uma boa satisfação do cliente, o software
precisará se integrar a outras ferramentas
moderado 80%
009 Cliente não conhece bem o seu problema e as
suas necessidades tecnológicas
moderado 30%
PONTO DE CORTE
010 Interferências de outros sistemas que estão em
execução no mesmo ambiente
moderado 10%
011 Dificuldades adversas em virtude da equipe
nunca ter trabalhado com o cliente anteriormente
marginal 65%
012 Curtos prazos de entrega marginal 60%
013 Equipe de desenvolvimento pequena marginal 30%
014 Perder informações da base de dados na fase de
homologação
marginal 20%

3.2 Redução e Gestão dos Riscos
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).
Risco: 001 Probabilidade: 45% Impacto: crítico
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 possuam maior familiaridade com as
tecnologias a serem utilizadas.
Plano de contingência: Contratar um consultor especialista no assunto para fazer o
acompanhamento do projeto.
Pessoa responsável: Equipe de Desenvolvimento.
Status: Concluído.
Descrição: Levantamento de requisitos falhos.
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 identicar 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: 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 vericações períodicas do produto ao cliente.
Plano de contingência: Procurar uma pessoa de confiança do cliente com maior dispo-
nibilidade e que esteja apta a colaborar com a equipe do projeto; estender os prazos para
entrega do projeto, de acordo com o aumento das diculdades em identicar as necessidades
do cliente.
Pessoa responsável: Gerente de Projetos.
Status: Em Andamento.

Descrição: Perceber durante a execução do projeto que o mesmo é maior do que o
esperado.
Estratégia de redução: Vericar o escopo do projeto a cada reunião.
Plano de contingência: Renegociar valores com o cliente; combinar entregas incrementais
do software.
Pessoa responsável: Gerente de Projetos.
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 identificadas.
Plano de contingência: Refatoração do código para reduzir o número de requisições rea-
lizadas e consumo de banda; realizar upgrade do servidor para adequar-se às necessidades.
Risco: 006 Probabilidade: 90% Impacto: moderado
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.
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 prio-
ridade; Custear horas extras e motivar financeiramente a equipe para que se dedique ao
projeto.
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 softwa-
res 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.

Descrição: Cliente não conhece bem o seu problema e as suas necessidades tecnológicas.
Estratégia de redução: Buscar identicar as necessidades do cliente durante a elicitação dos
requisitos, validá-los e explicar ao cliente como estas necessidades poderão ser supridas.
Plano de contingência: Estabelecer uma maior frequência de reuniões visando esclarecer
o que o cliente realmente necessita; manter a equipe de desenvolvimento em contato
frequente com os usuários.
Pessoa responsável: Equipe do Projeto.
Status: Em andamento.

23
4Planejamento Temporal
Nesta seção será definido o Modelo de Processo escolhido juntamente com a identificação
das tarefas a serem realizadas. Logo depois será apresentada a estrutura e organização dessas
tarefas de modo que seja estimada a duração total do projeto.
4.1 Conjunto de Tarefas do Projeto
Aqui são apresentados o Modelo de Processo escolhido e as suas atividades e tarefas
que foram escolhidas para serem apresentadas nesta secção. O Modelo de Processo Sequencial
Linear foi o escolhido para implantação do SIUR. Também conhecido como Modelo Cascata,
foi escolhido por se adaptar bem as necessidades do projeto e da equipe.
Como descrito no capítulo 2, o projeto será dividido em três etapas (planejamento,
codificação e testes) a serem executadas dentro do prazo de 100 dias úteis. Essas etapas foram
subdivididas em atividades específicas como reuniões, documentação, criação de diagramas,
protótipo e artefatos. Cada um desses itens podem ser identificados como uma tarefa.
4.2 Diagrama de Gantt
A Figura 4 contém o Diagrama de Gantt do projeto para implantação do SIUR. A
finalidade desse diagrama é organizar cronologicamente todas as tarefas a serem executadas
juntamente com informações como data inicial, data final e pessoas responsáveis. Foi definido
também que o projeto teria início no dia 02 de janeiro de 2018 e se encerraria em 26 de maio de
2018, completando os 100 dias úteis de projeto.

Capítulo4.PlanejamentoTemporal24
Figura 4 – Diagrama de Gantt
Fonte: GanttProject

Capítulo 4. Planejamento Temporal 25
4.3 Comparação com a realidade
Apesar dos prazos e datas estipulados nesse artigo, a implantação do SIUR seguiu outros
parâmetros. O sistema em questão foi desenvolvido durante a disciplina de Engenharia de
Software e demorou, aproximadamente, 10 meses para ser concluído. Após a entrega final do
produto de software para a disciplina, ele ficou em stand-by até o final do ano de 2017, quando a
mesma equipe começou a implantar o sistema no ambiente do Hospital Universitário.
Na primeira etapa, durante a disciplina, o desenvolvimento obedeceu as três etapas
estabelecidas pelo modelo Cascata: planejamento, codificação e testes. Já para essa segunda
etapa, de implantação, foi adotada uma metodologia mais iterativa e incremental. São realizadas
reuniões a cada 15 dias para discutir a modificação ou o acréscimo de funcionalidades e apresentar
os resultados obtidos da reunião anterior. Nessa segunda etapa foi estimado um prazo de 3 meses,
totalizando, aproximadamente, 13 meses desde o início do projeto até a disponibilização completa
do sistema em produção.

26
5Organização do Pessoal
Nesta seção é apresentada a distribuição dos recursos humanos no projeto, apontando
quais são as suas funções e responsabilidades. Além disso, são elencadas as ferramentas utilizadas
pela equipe durante o decorrer do projeto. Por fim, é feita uma breve análise da metodologia de
ensino baseada no uso do Edu-blog.
5.1 Estrutura da Equipe
A tabela a seguir exibe o papel básico de cada integrante, porém não limitando suas
atribuições no decorrer do processo de desenvolvimento do projeto.
Tabela 5 – Alocação de funções.
Profissional Função Atividades
Claudson Martins
e Edgar
Analista de Sistema /
Desenvolvedor
Realizar estudos de processos computaci-
onais, planejar e coletar informações junto
ao usuário com a nalidade de implantar o
projeto;
Transformar o projeto no sistema propria-
mente dito. Codificar.
Guilherme Boroni Gerente de Projeto / Ar-
quiteto de Software
Planejar, controlar e executar projetos,
atentando-se aos prazos e custos de produ-
ção; Liderar e coordenar as atividades e os
artefatos técnicos no decorrer do projeto.
5.2 Mecanismos de Comunicação
As ferramentas de comunicação utilizadas foram o Trello, E-mail, WhatsApp e Bitbucket.
Além disso, foram indispensáveis as reuniões esporádicas com os membros do projeto e o cliente.

Capítulo 5. Organização do Pessoal 27
O Trello foi utilizado para o gerenciamento das atividades do projeto e seu progresso com
o decorrer do tempo. O e-mail foi utilizado em maior frequência apenas para se comunicar com
o cliente, comunicação esta que se deu também por WhatsApp. Este aplicativo de mensagens
também foi bastante utilizado pelos membros do projeto para comunicação mais dinâmica e
informal. Todo o versionamento dos artefatos de software foram armazenados no repositório no
Bitbucket.
5.3 Uso do Edu-blog como Ferramenta de Apoio
Esta metodologia é bastante proveitosa pois faz com que o aluno busque sobre aquele
determinado assunto focando sempre em um aspecto especíﬁco, o qual será discutido em uma
postagem. Isto proporciona um conhecimento mais profundo sobre aquele tópico, contribuindo
na construção do arcabouço de conhecimento.
No entanto, é necessário que os temas discutidos pelas equipes sempre sejam temas que
despertem o interesse dos estudantes. Isto é fundamental pois desta maneira a pesquisa sobre
o tema ao longo do período dar-se-á de uma forma menos maçante e mais prazerosa, o que
não ocorre quando o tema não desperta interesse da equipe. Os temas clássicos são de extrema
relevância, mas poderiam ser abordados de outra maneira, abrindo espaço para que as novidades
e as tendências possam ser discutidas nos blogs.

28
Referências
MORAES, G. Sistema 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.
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.

Plano de Projeto de Software - SIUR

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (18)

Ähnlich wie Plano de Projeto de Software - SIUR

Ähnlich wie Plano de Projeto de Software - SIUR (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (8)

Plano de Projeto de Software - SIUR