1. O documento apresenta o plano de projeto de software para produtos da empresa Lacertae SW para o Hospital Universitário da UFS. 2. O software tem como objetivo gerenciar informações sobre ocorrências no hospital de forma a notificar os setores envolvidos. 3. Foram estimados 315 dias-pessoa de trabalho utilizando a técnica de Lorenz & Kidd com base no diagrama de classes do sistema.

1. UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Sistemas de Informação
Ademir Almeida da Costa Júnior
Alef Vinicius Andrade de Deus
Maryellen Maura Soares Martins
Rafael Reis de Assis
Plano de Projeto de Software para produtos da Lacertae SW
São Cristóvão-SE
2017

2. Ademir Almeida da Costa Júnior
Alef Vinicius Andrade de Deus
Maryellen Maura Soares Martins
Rafael Reis de Assis
Plano de Projeto de Software para produtos da Lacertae SW
Trabalho apresentado ao Prof. Dr. Rogério Patrício
Chagas do Nascimento como nota para disciplina
Gerência de Projetos do curso de graduação em
Sistemas de Informação – Bacharelado da Universidade
Federal de Sergipe (UFS).
São Cristóvão-SE
2017
1

3. SUMÁRIO
1 INTRODUÇÃO …………………………………………………………………………... 06
1.1 Âmbito do Projeto ………………………………………………………………. 06
1.2 Funções principais do produto de software ……………………………………... 06
1.3 Requisitos comportamentais ou de performance ……………………………….. 07
1.4 Gestão e restrições técnicas ……………………………………………………... 08
2 ESTIMAÇÕES DO PROJETO ………………………………………………………….... 08
2.1 Dados históricos utilizados para as estimações …………………………………. 08
2.2 Técnicas de estimação e resultados ……………………………………………... 08
2.2.1 Técnica de estimação …………………………………………………. 08
2.3 Resultados ………………………………………………………………………. 09
2.4 Recursos do projeto ………………………………………………………..……. 10
2.4.1 Recursos Humanos ……………………………………………………. 10
2.4.2 Requisitos Necessários para o Sistema Funcionar ……………....……. 10
2.4.3 Software de Suporte …..…………………………………………....…. 11
3 ANÁLISE E GESTÃO DE RISCOS ……………………………………………….…….. 11
3.1 Riscos do projeto ………………………………………………………………... 12
3.2 Tabela de Riscos …………………………...…………………………….…...….
13
3.3 Redução e gestão do risco …………………………………………………....…. 14
4 PLANEJAMENTO TEMPORAL ………………………………..……………………...…19
4.1 Conjunto de Tarefas do Projeto …………...…………………………….……….
19
4.2 Diagrama de Gantt …………………………………………………………….... 20
5 ORGANIZAÇÃO DO PESSOAL ……………………………………………….………...22
5.1 Estrutura da equipe ……………………………………………………....……… 22
5.2 Mecanismos de comunicação …………………………………………………… 22
5.3 Uso do Edu-blog como ferramenta de apoio …………………………………… 23
6 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE
DO PRODUTO DE
SW…………………………………………....………………..…………… 23
2

4. 7 REFERÊNCIAS ………………….…………....…………………….……...……….……24
3

5. LISTA DE FIGURAS
Figura 1 - Diagrama de Caso de Uso do SGO..………………………………………………07
Figura 2 - Diagrama de Classes SGO….……..………………………………………………10
Figura 3 - Gráfico de Gantt ……....…………..………………………………………………21
4

6. LISTA DE TABELAS
Tabela 1 - Interface e multiplicadores ……………………………..…………………………09
Tabela 2 - Probabilidade dos Riscos …..…………………………..…………....……………13
Tabela 3 - Riscos do Projeto
...……………………………………..…………………………13
Tabela 4 - Relação das tarefas e dias de trabalho…………………..…...……………………
20
5

7. LISTA DE QUADROS
Quadro 1 - Riscos e suas classificações por área …………………..…...……………………12
Quadro 2 - Estratégia R001 …………………………………………..………………………14
Quadro 3 - Estratégia R002 ……………………………………....……..……………………15
Quadro 4 - Estratégia R003 ………………………………………...……..………………….15
Quadro 5 - Estratégia R004 …………………………………………...……..……………….15
Quadro 6 - Estratégia R005 ……………………………………………...……..…………….16
Quadro 7 - Estratégia R006 ………………………………………………...……..………….16
Quadro 8 - Estratégia R007 …………………………………………………...……..……….17
Quadro 9 - Estratégia R008 ……………………………………………………...……..…….17
Quadro 10 - Estratégia R009 ………………………………………………………...……….17
Quadro 11 - Estratégia R010 …………………………………………………………...…….17
Quadro 12 - Estratégia R011 ……………………………………………………………....…18
Quadro 13 - Estratégia R012 ………………………………………………………………....19
Quadro 14 - Integrantes da equipe e atribuições ……………………………………..………22
6

8. 1 INTRODUÇÃO
Nesta seção serão apresentados os conceitos básicos relacionados ao Sistema de
Gestão de Ocorrências (SGO), necessidades a serem atendidas, principais funções e seu
âmbito. Este documento especifica os requisitos funcionais levantados do SGO. Tais
requisitos foram levantados após entrevista com o cliente, observações e análise da situação
atual do hospital.
1.1 Âmbito do projeto
O Sistema de Gestão de Ocorrências (SGO) tem como objetivo gerenciar informações
de ocorrências no Hospital Universitário da Universidade Federal de Sergipe (HU-UFS).
Vinculado à Universidade Federal de Sergipe desde 1884, o HU é totalmente integrado com o
SUS (Sistema Único de Saúde), possui 123 leitos, 68 consultórios e se destaca por ser
referência na prestação de assistência médico-hospitalar de média e alta complexidade. No
Hospital Universitário, existe a demanda por um sistema que consiga efetuar registros,
monitoramento e alertas sobre ocorrências, previstas ou não, que afetam o funcionamento do
hospital.
O Sistema será criado para a plataforma Web, de modo a atender a uma maior parcela
de usuários. O sistema provê uma visão geral dos acontecimentos proporcionando ao gestor
melhor tomada de decisão na distribuição dos recursos.
1.2 Funções principais do produto de software
As ocorrências são atividades identificadas e planejadas que afetam a rotina do
hospital, como aparelhos com defeito ou alguma manutenção prevista que possa
impossibilitar o uso de um determinado espaço. As informações de ocorrências e a interação
dos usuários para a sua solução são cadastradas pelos colaboradores da instituição e, ao
cadastrar, notificações são emitidas aos usuários relacionados ao setor responsável. Com isso,
os principais envolvidos ficam cientes da ocorrência e podem remanejar suas consultas ou
atividade a ser desenvolvida no local. A solução da ocorrência acontece no momento em que
após uma ou mais interações, ou comentários, uma última interação é marcada como solução
7

9. para ocorrência.
Para atender a necessidade do HU, o SGO contém um conjunto de funcionalidades
relacionadas a manutenção, ou seja, cadastro, exclusão e edição das informações de usuários
colaboradores e seus perfis de acesso, locais ou endereços de qualquer parte que existe no
hospital, setores, tipos de ocorrência, ocorrência e o descritivo de sua solução através de
interações entre os setores e usuários relacionados a cada ocorrência. Além da manutenção
das informações, o SGO efetua a geração de log de dados das operações feitas no sistema para
se ter um histórico das alterações e para fins de auditoria quando necessário. Além disso ele
dispõe de controle de acesso ao sistema com login e senha, emissão de relatórios referente as
ocorrências, como ocorrências solucionadas ou em aberto, e geração de alertas para os
usuários do sistema. As funcionalidades do sistema podem ser melhor entendidas e
visualizadas na Figura 1, apresentada abaixo, que apresenta o diagrama de caso de uso do
sistema.
Figura 1 - Diagrama de Caso de Uso do SGO
1.3 Requisitos comportamentais ou de performance
8

10. Para o correto funcionamento do SGO, o sistema deve se adequar aos recursos
dispostos no ambiente do hospital universitário, o sistema deve atender aos seguintes
requisitos:
● Ser desenvolvido na linguagem de programação Java , versão Web;1
● Utilizar banco de dados Postgresql , na versão 8.4 ou posterior;2
● O servidor de aplicação utilizado deve ser o Tomcat na versão 7.3
1.4 Gestão e restrições técnicas
A equipe disponível para execução do projeto não possui experiência na tecnologia
exigida pelo cliente. Além disso, o projeto possui data de entrega pouco flexível e a falta de
recursos do hospital, como instituição pública, pode inviabilizar a manutenção do software
após sua entrega.
O processo de software utilizado deve abordar a metodologia SCRUM em seu4
desenvolvimento. Por isso, logo após a especificação dos requisitos através de entrevista e
acompanhamento da rotina do hospital, essa metodologia ágil deve ser adotada para as fases
de desenvolvimento e verificação do produto a ser desenvolvido.
2 ESTIMAÇÕES DO PROJETO
2.1 Dados históricos utilizados para as estimações
Este é o primeiro projeto a ser realizado pela equipe, portanto não será possível
utilizar dados históricos para as estimações do mesmo.
2.2 Técnicas de estimação e resultados
1
​Linguagem de programação orientada a objetos desenvolvida na década de 90 por uma equipe de
programadores chefiada por James Gosling, na empresa Sun Microsystems. Disponível em
https://www.oracle.com/java/index.html
2
Sistema gerenciador de banco de dados objeto relacional (SGBDOR), desenvolvido como projeto de código
aberto. Disponível em https://www.postgresql.org/
3
​Servidor web Java, mais especificamente, um container de servlets. Disponível em http://tomcat.apache.org/
4
​Scrum é uma metodologia ágil para gestão e planejamento de projetos de software. Disponível em
https://www.scrum.org/
9

11. 2.2.1 Técnica de estimação
O projeto SGO seguirá a técnica de mensuração proposta pela Lacertae SW, para isso
é necessário que o software seja desenvolvido usando o paradigma de Orientação a Objeto
(OO) .5
A técnica utilizada para a estimação e resultados foi a de Lorenz & Kidd . Trata-se de6
uma técnica orientada a classes que dá como resultado uma estimativa do esforço necessário
para desenvolver o software. O que se faz nessa técnica basicamente é decompor os esforços
usando como parâmetros o número de classes-chave, responsáveis pela estimativa de esforço
final do sistema. Há também as classes de suporte, que são classes que não fazem parte do
domínio do problema, geralmente representam a interface gráfica do sistema (botões, janelas,
etc).
Um ponto importante desta técnica é a classificação da interface do produto, que
resultará no multiplicador para as classes de suporte, de acordo com a Tabela 1.
Interface Multiplicador
Não gráfica 2,0
Baseada em texto 2,25
GUI 2,5
GUI complexa 3,0
Tabela 1 - Interface e multiplicadores
2.3 Resultados
A partir do diagrama de classes de domínio, exibido na Figura 2, e a técnica de Lorenz
& Kidd, obteve-se as seguintes informações:
● 5 Classes chaves: Colaborador, Mensagem, Setor, Ocorrência e Resolução;
5
É um paradigma para o desenvolvimento de software que baseia-se na utilização de componentes individuais
(objetos) que colaboram para construir sistemas mais complexos. A colaboração entre os objetos é feita através
do envio de mensagens. Disponível em
https://pt.wikibooks.org/wiki/Programa%C3%A7%C3%A3o_Orientada_a_Objetos/Introdu%C3%A7%C3%A3o
6
Autores responsáveis por criar métricas para softwares orientados a objeto. Disponível em:
http://dl.acm.org/citation.cfm?id=177063
10

12. ● Tipo de interface: GUI (2,5);
● Classes de suporte: 5 (classes de domínio) X 2,5 (fator multiplicador) = 12,5
classes;
● Total de classes: 5 (classes chaves) + 12,5 (classes de suporte) = 17,5 classes;
● Como unidade média de trabalho por classe, utilizaremos 18 dias por pessoa,
totalizando 315 dias-pessoa.
Figura 2 - Diagrama de Classes do SGO
2.4 Recursos do projeto
Para o funcionamento do projeto, fez-se necessário o uso de recursos humanos,
de software e hardware, os quais serão descritos nos itens a seguir.
2.4.1 Recursos Humanos
11

13. A equipe é composta por um gestor de projetos, um analista de sistemas, um
administrador de banco de dados e um analista de teste. Todos os membros da equipe
possuem suas atividades bem delimitadas e elas serão expostas na seção 5.1 (Estrutura
da equipe) deste documento.
2.4.2 Requisitos Necessários para o Sistema Funcionar
Para a correta instalação e configuração do software é necessário a seguinte
configuração de hardware:
● Windows 7 ou Superior;
● Memória RAM mínima de 1GB;
● Memória recomendada de 2GB;
● Espaço mínimo no disco 250MB;
● Espaço recomendado no disco de 500MB.
2.4.3 Software de Suporte
O sistema será desenvolvido utilizando a tecnologia Web, necessitando das
seguintes ferramentas:
● Ambiente para desenvolvimento Java (Eclipse IDE + JDK);7
● Software de Banco de Dados (PostgreSQL);
● Apache Tomcat 7.0;
● Bootstrap ;8
● StarUML ;9
● Apache Subversion (SVN) .10
3 ANÁLISE E GESTÃO DE RISCOS
Nesta seção serão apresentados os possíveis riscos do projeto, como serão
gerenciados. Diante da existência dos riscos, foi feito um brainstorming dos riscos potenciais
7
Ambiente de Desenvolvimento Integrado para desenvolvimento Java. Disponível em https://eclipse.org/
8
É um framework web front-end livre e de código aberto para a criação de websites e aplicações web.
Disponível em http://getbootstrap.com/
9
É uma ferramenta UML do MKLab. Disponível em http://staruml.io/
10
É um sistema de controle de versão. Disponível em https://subversion.apache.org/
12

14. para o projeto de acordo com as necessidades e restrições do software.
Para a gestão de riscos ser possível, executamos os procedimentos que seguem:
● Cada membro do grupo identificou uma lista de riscos individualmente;
● Logo após, para cada risco listado foi atribuído uma probabilidade e um
impacto de acordo com uma classificação pré definida pela equipe;
● Em equipe, juntamos todas as listas e fizemos uma análise circular em relação
às probabilidades e impacto;
● A lista de riscos foi organizada em ordem decrescente em relação ao impacto
e probabilidade;
● Por fim, foi feito o Plano de Redução, Supervisão e Gestão do Risco (RSGR),
definindo para cada risco uma Estratégia de Redução, um Plano de
Contingência e o(s) Responsável(eis) pela execução.
3.1 Riscos do projeto
A partir da Análise Circular feita pela equipe, o quadro abaixo foi elaborado contendo
todos os riscos e sua classificação por área:
ID Riscos Projeto Técnico Negócio Comum Especial
R001 Cliente não tem muito
tempo para
levantamento de
requisitos
X
R002 Perda de algum dado
do banco
X
R003 O sistema ficar
indisponível
X X
R004 Equipe de
desenvolvimento
pequena
X X
R005 Mudança de
requisitos durante o
desenvolvimento
X X
R006 Excesso de
requisições de páginas
ao servidor
X X
R007 Problemas com X X
13

15. interação entre
sistemas diferentes
R008 Pouco treinamento
dos usuários
X X
R009 Atividades mal
distribuídas
X X
R010 Perda de membros da
equipe
X X
R011 Expectativas não
satisfeitas
X X X
R012 Baixo conhecimento
prévio dos usuários
X X
Quadro 1 - Riscos e suas classificações por área.
A Tabela 2, foi elaborada para facilitar a classificação dos riscos atribuindo uma
probabilidade para cada um deles.
Classificação Probabilidade
Muita baixa ≤ 10%
Baixa > 10% e ≤ 25%
Média > 25% e ≤ 50%
Alta > 50% e ≤ 75%
Muito alta > 75%
Tabela 2 - Probabilidade dos riscos
3.2 Tabela de riscos
A Tabela 3 mostra os riscos identificados, a sua probabilidade de ocorrência e o
impacto esperado.
ID Riscos Probabilidade Impacto
R001 Cliente não tem muito tempo 70% Catastrófico
14

16. para levantamento de requisitos
R002 Perda de algum dado do banco de
dados
60% Catastrófico
R003 O sistema ficar indisponível 10% Catastrófico
R004 Equipe de desenvolvimento
pequena
70% Crítico
R005 Mudança de requisitos durante o
desenvolvimento
40% Crítico
R006 Excesso de requisições ao
servidor
30% Crítico
R007 Problemas com Interação entre
sistemas diferentes
30% Crítico
R008 Pouco treinamento dos usuários 25% Crítico
R009 Atividades mal distribuídas 25% Crítico
R010 Rotatividade dos membros da
equipe de desenvolvimento
10% Crítico
R011 Expectativas não satisfeitas 15% Marginal
R012 Baixo conhecimento prévio dos
usuários
10% Marginal
Tabela 3 - Riscos do projeto
3.3 Redução e gestão do risco
Para garantir a Redução, Supervisão e Gestão dos Riscos (RSGR) foram
utilizadas as seguintes estratégias mostradas do Quadro 1 até o Quadro 13:
ID​: R001 Probabilidade​: 70% Impacto​: Catastrófico
Risco: ​Cliente não tem muito tempo para levantamento de requisitos.
Descrição​: Cliente não tem muito tempo disponível para discutir os requisitos do Projeto.
Estratégia de redução​: Preparar-se bem para entrevistas, gravá-la para consultas futuras e
seguir notas e depoimentos no projeto.
Plano de contingência​: Solicitar ao cliente que indique uma pessoa disponível para esta
15

17. etapa do projeto. Esta pessoa deve conhecer o negócio e saber expressar o que o cliente
deseja.
Pessoal Responsável:​ Maryellen Martins.
Status​: Concluído.
Quadro 2 - Estratégia R001
ID​: R002 Probabilidade​: 60% Impacto​: Catastrófico
Risco: ​Perda de algum dado do banco de dados.
Descrição​: Possibilidade de haver alguma falha no banco de dados e perder dados
importantes.
Estratégia de redução​: Utilizar espelhamento de banco de dados.
Plano de contingência​: Determinar o uso de uma política de backup que deverá ser revista
pelo menos uma vez ao ano sempre buscando minimizar a perda de dados e acelerar
qualquer recuperação necessária.
Pessoal Responsável:​ Ademir Almeida.
Status​: Em andamento.
Quadro 3 - Estratégia R002
ID​: R003 Probabilidade​: 10% Impacto​: Catastrófico
Risco: ​O sistema ficar indisponível.
Descrição​: A não disponibilidade do sistema pode gerar prejuízo para a Lacertae SW.
Como também, gerará insatisfação nos usuários e insegurança quanto à qualidade do
software, o que poderá resultar na sua não utilização caso ocorra com frequência.
Estratégia de redução​: Deverão ser utilizadas ferramentas para diagnosticar todo o
ambiente onde o software estiver instalado. Ferramentas de monitoramento de banco de
dados e aplicações. Também deverão ser utilizadas estratégias de replicação para o banco
de dados e para a aplicação.
Plano de contingência​: Os processos a Lacertae não podem parar, logo na
indisponibilidade do sistema, planilhas e formulários impressos deverão ser utilizados. E
em paralelo o ambiente deverá ser reiniciado e os logs das ferramentas de monitoramento
deverão ser analisados, a fim de, identificar e corrigir a falha.
Pessoal Responsável:​ Alef de Deus e Ademir Almeida.
Status​: Em andamento.
16

18. Quadro 4 - Estratégia R003
ID​: R004 Probabilidade​: 70% Impacto​: Crítico
Risco: ​Equipe de desenvolvimento pequena.
Descrição​: Ter uma equipe de desenvolvimento pequena pode acarretar em atrasos na
entrega do produto se o escopo exigido pelo projeto for maior do que a equipe possa dar
conta.
Estratégia de redução​: Se o escopo do projeto requer mais tempo do que foi planejado, as
datas e prazos deverão ser replanejadas para adequar ao tamanho da equipe.
Plano de contingência​: Caso não haja tempo suficiente para completar a desenvolvimento
do produto, será necessário decidir quais funcionalidades serão efetivamente concluídas.
Será necessário reunir todos os envolvidos do projeto para tomarem essa decisão, a fim de,
não comprometer a utilização mínima do software.
Pessoal Responsável:​ Maryellen Martins.
Status​: Em andamento.
Quadro 5 - Estratégia R004
ID​: R005 Probabilidade​: 40% Impacto​: Crítico
Risco: ​Mudança de requisitos durante o desenvolvimento.
Descrição​: Mudanças fazem parte do dia a dia dos projetos de software. O cliente não
consegue passar todas as suas exigências logo no início do projeto. Além das alterações dos
requisitos ao longo do desenvolvimento.
Estratégia de redução​: Aplicar mais de uma técnica para elicitação de requisitos; Para
cada requisito que for feito a elicitação, aplicar verificação e validação para que não haja
inconsistências; especificar em contrato que mudanças nos requisitos acarretará em
mudança no prazo de entrega e custo do projeto.
Plano de contingência​: Redefinir cronograma do projeto incluindo as alterações
solicitadas.
Pessoal Responsável:​ Maryellen Martins.
Status​: Em andamento.
Quadro 6 - Estratégia R005
ID​: R006 Probabilidade​: 30% Impacto​: Crítico
Risco: ​Excesso de requisições ao servidor.
17

19. Descrição​: Descrição: Alto número de requisições pode congestionar a rede, deixando o
sistema lento ou até causando a sua interrupção, dependendo apenas do nível de sobrecarga
das requisições.
Estratégia de redução​: Escolher servidor adequado com base na projeção de utilização do
sistema.
Plano de contingência​: Upgrade ou migração para um servidor que comporte a quantidade
de acessos simultâneos; limitar o número de acessos ao site, por meio de uma fila virtual de
atendimento.
Pessoal Responsável:​ Alef de Deus , Rafael Reis, Ademir Almeida.
Status​: Em andamento.
Quadro 7 - Estratégia R006
ID​: R007 Probabilidade​: 30% Impacto​: Crítico
Risco: ​Problemas com Interação entre sistemas diferentes.
Descrição​: Outros sistemas da Lacertae deverão comunicar-se indiretamente com o
sistema.
Estratégia de redução​: Realizar uma ampla gama de testes para garantir o funcionamento
correto.
Plano de contingência​: Corrigir as falhas detectadas na fase de testes do software e dos
adaptadores que serão utilizados para as comunicações com os sistemas.
Pessoal Responsável:​ Alef de Deus e Rafael Reis.
Status​: Em andamento.
Quadro 8 - Estratégia R007
ID​: R008 Probabilidade​: 25% Impacto​: Crítico
Risco: ​Pouco treinamento dos usuários.
Descrição​: O treinamento é uma etapa importante na adoção de uma nova ferramenta de
trabalho. É através dele que dúvidas sobre o funcionamento e manuseio do software serão
sanadas. A falta de treinamento ou mesmo sua pouca execução pode ocasionar o manuseio
incorreto do software causando erros de informações e ou interpretações. Como também,
um descontentamento na utilização do mesmo.
Estratégia de redução​: A implantação do software deverá contemplar um período hábil
para treinamento dos usuários, como também o acompanhamento mais efetivo nos
primeiros meses após a implantação.
18

20. Plano de contingência​: Produzir documentação do sistema, guias, manuais, vídeo aulas e
realizar treinamentos e acompanhamento mais efetivos nos primeiros meses de execução.
Pessoal Responsável:​ Rafael Reis.
Status​: Em andamento.
Quadro 9 - Estratégia R008
ID​: R009 Probabilidade​: 25% Impacto​: Crítico
Risco: ​Atividades mal distribuídas.
Descrição​: Atividades mal distribuídas entre os membros da equipe de desenvolvimento.
Estratégia de redução​: Distribuir as atividades de forma correta, avaliando a experiência e
carga de trabalho atual dos colaboradores.
Plano de contingência​: Rever cronograma e redistribuir as atividades a fim de evitar
situação em que algumas pessoas fazem tarefas demais e outras poucas, gerando ciúmes e
mal-entendidos.
Pessoal Responsável:​ Maryellen Martins.
Status​: Concluído.
Quadro 10 - Estratégia R009
ID​: R010 Probabilidade​: 10% Impacto​: Crítico
Risco: ​Rotatividade dos membros da equipe de desenvolvimento.
Descrição​: É comum haver rotatividades nas equipes de desenvolvimento (como exemplo,
esta equipe em especial é composta por alunos, onde os mesmos podem abandonar a
disciplina a qualquer momento). Com isso a equipe pode ficar reduzida e
consequentemente a entrega do projeto poderá atrasar.
Estratégia de redução​: Para diminuir os possíveis atrasos decorrentes da saída de
membros da equipe, algumas medidas podem ser tomadas, tais como: diminuir o escopo do
projeto, replanejar a data de entrega, dividir melhor as tarefas entre os membros restantes
ou (em último caso) recrutar novos integrantes para a equipe.
Plano de contingência​: Se nenhuma medida da estratégia de redução for efetiva os
gestores do projeto juntamente como o ​ Product Owner deverão decidir como o projeto será
continuado ou mesmo se deverá ser abortado.
Pessoal Responsável:​ Maryellen Martins.
Status​: Em andamento.
19

21. Quadro 11 - Estratégia R010
ID​: R011 Probabilidade​: 15% Impacto​: Marginal
Risco: ​Expectativas não satisfeitas.
Descrição​: Apesar do acompanhamento do cliente no desenvolvimento do produto de
software, o mesmo pode não ficar satisfeito com o que foi entregue.
Estratégia de redução​: Verificar quais são as expectativas do cliente, e separá-las por
nível de importância e buscar sempre alcançar as mais importantes.
Plano de contingência​: Buscar no próximo projeto satisfazer as expectativas do cliente.
Pessoal Responsável:​ Alef de Deus e Rafael Reis.
Status​: Em andamento.
Quadro 12 - Estratégia R011
ID​: R012 Probabilidade​: 10% Impacto​: Marginal
Risco: ​Baixo conhecimento prévio dos usuários.
Descrição​: A equipe não tem conhecimento prévio dos usuários.
Estratégia de redução​: A equipe deve manter contato com os usuários após as reuniões,
para caso seja necessário, sanar qualquer dúvida mesmo antes das reuniões seguintes já
definidas.
Plano de contingência​: Aumentar o número de reuniões com os stakeholders como uma
medida de sanar qualquer dúvida que exista entre todas as partes.
Pessoal Responsável:​ Maryellen Martins.
Status​: Em andamento.
Quadro 13 - Estratégia R012
4 PLANEJAMENTO TEMPORAL
Nesta seção apresenta-se as tarefas e as suas dependências de forma a estimar a
duração total do projeto.
4.1 Conjunto de Tarefas do Projeto
20

22. A metodologia de desenvolvimento de software escolhida foi a Scrum.
Metodologias ágeis de desenvolvimento de software são iterativas, ou seja,
funcionalidades vão sendo entregues a cada Sprint (iteração), no caso da Scrum. A
Tabela 4 mostra o conjunto de tarefas em macro deste projeto e relação com a
porcentagem de dias de trabalho:
Tarefas Macro Dias de Trabalho Porcentagem
Planejamento 3 4%
Análise de Requisitos e Modelagem 30 38%
Codificação 16 20%
Testes 30 38%
Tabela 4 - Relação das tarefas e dias de trabalho
4.2 Diagrama de Gantt
Para gerenciamento de tempo do projeto, estimando a duração de cada atividade
deste projeto, foi elaborado um gráfico de Gantt. Na Figura 3, podemos ver como as
atividades foram definidas ao longo das semanas que estimam o tempo do projeto.
21

23. 22

24. 5 ORGANIZAÇÃO DO PESSOAL
Nesta seção, será explanado sobre os recursos humanos que compõem a elaboração
desse projeto e o papel de cada um.
5.1 Estrutura da equipe
A equipe é composta pelos seguintes integrantes: Ademir Júnior, Alef de Deus,
Maryellen Martins e Rafael Reis. O Quadro 14 mostra o papel de cada integrante da
equipe no projeto.
Integrante Papel Descrição da atividade
Ademir Júnior Administrador de Banco de Dados Gerenciar, instalar,
configurar, atualizar e
monitorar o sistema de
banco de dados.
Alef de Deus Analista de Sistema Analisar e desenvolver o
sistema, mapear processos,
modelar dados e levantar os
requisitos
Maryellen Martins Gerente de Projeto Definir os papéis e funções
dos integrantes do projeto,
além de acompanhar e gerir
o trabalho de todos os
envolvidos no projeto.
Rafael Reis Analista de Teste Planejar e executar os casos
de testes para garantir o
cumprimento dos requisitos
do sistema, além disso o
analista será responsável
pelo treinamento dos
usuários do sistema.
Quadro 14 - Integrantes da equipe e atribuições
5.2 Mecanismos de comunicação
O principal mecanismo de comunicação entre a equipe foi o Trello aliado ao
23

25. Whatsapp. O Trello é uma ferramenta versátil que permite o gerenciamento de projetos
através de listas, qualquer atividade alterada no ambiente do projeto criado no Trello é
notificado a todos da equipe. O Whatsapp por outro lado fornece uma comunicação imediata
com todos os integrantes, através do grupo criado na aplicação.
Além de permitir a comunicação o Trello permite o monitoramento das atividades do
projeto. As reuniões também ficam agendadas na aplicação que permite o uso de calendários,
notificações e anexo de arquivos, como atas das reuniões.
5.3 Uso do Edu-blog como ferramenta de apoio
Com o uso do Edu-blog, foi possível reunir as ideias dos componentes do grupo, além
de permitir o conhecimento dos assuntos abordados por outras equipes de projeto da
disciplina. Disseminar o conhecimento foi outro ponto importante, pois percebe-se que além
de atingir integrantes de outras equipes da turma, ele trouxe leitores além das barreiras
regionais.
O aprendizado de novas ferramentas ajudaram o desenvolvimento deste trabalho, pois
através do Edu-blog pode-se comparar as principais ferramentas do mercado e escolher qual
melhor se adapta às nossas necessidades. Por fim, as discussões feitas por meio dos
comentários só agregaram conhecimento.
6 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE
DO PRODUTO DE SOFTWARE
Qualidade é um termo bastante generalizado, pois dependerá das necessidades do
cliente. Segundo Pressman (2009) “Qualidade de software é a conformidade a requisitos
funcionais e de desempenho que foram explicitamente declarados, a padrões de
desenvolvimento claramente documentados, e a características implícitas que são esperadas
de todo software desenvolvido por profissionais.
Portanto, o primeiro ponto a ser levado em conta foram as necessidades do cliente.
Tentou-se mantê-lo o mais próximo possível de todas as fases do projeto para evitar
problemas durante a fase de desenvolvimento do produto.
O segundo ponto foram os testes de software. Durante o desenvolvimento foram
24

26. utilizados os seguintes testes de software: unitário, interação, performance, aceitação do
usuário, configuração, segurança.
O terceiro ponto foram as revisões de técnicas formais realizadas na etapa de análise e
projeto, visando à identificação de erros nas fases iniciais do projeto, onde o custo para a
manutenção foi reduzido.
O quarto ponto foi a utilização correta de métricas para identificar características do
software e ter noção de que os requisitos estão consistentes e completos.
Por fim, procurou-se manter a maior transparência possível entre a equipe, para isso as
reuniões entre os membros da equipe responsável pelo projeto foram constantes. E quando
estas não podiam ser realizadas, as ferramentas de comunicação listadas neste projeto
ajudaram a manter o canal de comunicação sempre disponível e transparente. Como resultado,
todos estavam cientes das alterações do software, dos diagramas e documentação durante todo
ciclo de desenvolvimento.
7 REFERÊNCIAS
PRESSMAN, R. Software Engineering: A Practitioner’s Approach [S.l.]: McGraw-Hill
Education, 2009. ISBN 0073375977.
SCHWABER, J. S. K. The Definitive Guide to Scrum: The Rules of the Game. 2016.
Disponível em:
<http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf#zoo100>.
SOMMERVILLE, I. Software Engineering (9th Edition). [S.l.]: Pearson, 2010. ISBN
0137035152.
STAIR, R.; REYNOLDS, G. Fundamentals of information systems. [S.l.]: Cengage
Learning, 2012.
25