O documento apresenta um plano de projeto de software para um sistema de monitoramento de eventos adversos, destinado ao setor de enfermagem do Hospital Universitário da Universidade Federal de Sergipe. Ele inclui estimativas de esforço, análise de riscos e a organização da equipe envolvida no desenvolvimento do projeto, bem como as principais funcionalidades e requisitos do software. O projeto visa gerar uma base de conhecimento sobre eventos adversos, facilitando a gestão e minimização desses incidentes.

1. UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
PLANO DE PROJETO DE SOFTWARE PARA O MEA
Plano de Projeto de Software
Mayk Willians Santos Menezes, Alan Felix da Mota e Lucas dos
Santos Aquino
Departamento de Computação/UFS
São Cristóvão – Sergipe
2018

2. UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Mayk Willians Santos Menezes, Alan Felix da Mota e Lucas dos
Santos Aquino
PLANO DE PROJETO DE SOFTWARE PARA O MEA
Plano de Projeto de Software submetido à disciplina
de Gestão de Projetos como requisito parcial para a
obtenção da nota final.
Docente: Prof. Dr. Rogério Patrício Chagas do Nasci-
mento
São Cristóvão – Sergipe
2018

3. Lista de ilustrações
Figura 1 – Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4. Lista de tabelas
Tabela 1 – Principais Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Tabela 2 – Tabela de pesos de cada categoria de classe . . . . . . . . . . . . . . . . . . 9
Tabela 3 – Estimativas de cada etapa do projeto . . . . . . . . . . . . . . . . . . . . . 10
Tabela 4 – Tabela de riscos do MEA . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Tabela 5 – Risco 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Tabela 6 – Risco 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Tabela 7 – Risco 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Tabela 8 – Risco 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Tabela 9 – Risco 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Tabela 10 – Risco 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Tabela 11 – Risco 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Tabela 12 – Risco 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Tabela 13 – Risco 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Tabela 14 – Tempo estimado de cada tarefa macro do projeto . . . . . . . . . . . . . . . 17
Tabela 15 – Divisão de Funções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5. Lista de abreviaturas e siglas
SI Sistema de Informação
UFS Universidade Federal de Sergipe
IDE Integrated Development Environment
MEA Monitoramento de Eventos Adversos
HU Hospital Universitário
UML Unified Modeling Language
SQA Software Quality Assurance
PDF Portable Document Format
ISO International Organization for Standardization
IEC International Electrotechnical Commission
CMMI Capability Maturity Model Integration
MPS.BR Melhoria de Processo de Software Brasileiro

6. Sumário
1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1 Âmbito do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Funções principais do produto de software . . . . . . . . . . . . . . . . . . . . 6
1.3 Requisitos comportamentais ou de performance . . . . . . . . . . . . . . . . . 6
1.4 Gestão e Restrições Técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Estimação do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 Dados históricos utilizados para estimações . . . . . . . . . . . . . . . . . . . 8
2.2 Técnicas de estimação e resultados . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Técnica de estimação . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Recursos do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 Recursos humanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2 Recursos de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3 Recursos de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.4 Recursos Bibliográficos . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Análise e Gestão de Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Riscos do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Redução e gestão do risco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Planejamento Temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 Conjunto de tarefas do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5 Organização da Equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1 Estrutura da equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Mecanismos de comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3 Uso do Edu-blog como ferramenta de apoio . . . . . . . . . . . . . . . . . . . 21
6 Precauções a Serem Tomadas para Assegurar e Controlar a Qualidade do Pro-
duto de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
ANEXO A Diagrama de classes de projeto . . . . . . . . . . . . . . . . . . . . . . 24

7. 6
1Introdução
1.1 Âmbito do Projeto
O MEA é um sistema de Monitoramento de Eventos Adversos desenvolvido para auxiliar
o trabalho do setor de enfermagem do Hospital Universitário.
O software permite que o usuário crie, edite e preencha questionários de pacientes. O
objetivo é gerar uma base de conhecimento sobre os eventos adversos que ocorrem diariamente
e traçar metas para minimizá-los.
1.2 Funções principais do produto de software
As funcionalidades e seus respectivos usuários serão listados na Tabela 1 abaixo:
Tabela 1 – Principais Funcionalidades
Funcionalidade Usuário
Preencher Dados Usuário
Efetuar Login Usuário
Manter Formulário Gerente
Gerar Relatório Gerente
Visualizar Dados Gerente
Manter Cadastros Adminstrador
Importar usuário Adminstrador
1.3 Requisitos comportamentais ou de performance
Para melhor atender aos seus usuários, o sistema dispõe dos seguintes requisitos:
1. Usabilidade: O sistema deve apresentar interface amigável e de fácil entendimento.

8. Capítulo 1. Introdução 7
2. Confidencialdade: O sistema deverá estar disponível 24 horas por dia durante, 7 dias por
semana.
3. Segurança: O sistema deve garantir a integridade das informações.
1.4 Gestão e Restrições Técnicas
Temos as seguintes restrições técnicas:
1. A linguagem de programação deverá ser Java.
2. O sistema de gerenciamento de Banco de Dados deverá ser o PostgreSQL.

9. 8
2Estimação do Projeto
Esta parte do documento fornece estimativas relacionadas ao custo, trabalho e tempo
de desenvolvimento do projeto. As estimativas foram calculadas de acordo com as métricas de
Lorenz e Kidd (LORENZ; KIDD, 1994). Essas métricas foram escolhidas por se adequarem
bem ao desenvolvimento de softwares construídos de acordo com o paradigma da orientação a
objetos, como é o caso deste software.
2.1 Dados históricos utilizados para estimações
Por ser o primeiro projeto desenvolvido por esta equipe, não dispomos de um parâmetro
histórico para as estimativas.
2.2 Técnicas de estimação e resultados
2.2.1 Técnica de estimação
Para utilizar as métricas de Lorenz (LORENZ; KIDD, 1994), é preciso seguir as seguintes
etapas:
1. Verificar quantas classes chave existem no sistema, que são as classes ligadas diretamente
as regras de negócio;
2. Definir o tipo de interface do sistema, e associá-la a um multiplicador de acordo com sua
complexidade.
Para isso, categorizamos as interfaces de acordo com a Tabela 2 abaixo:

10. Capítulo 2. Estimação do Projeto 9
Tabela 2 – Tabela de pesos de cada categoria de classe
Interface Multiplicador
Não gráfica 2,0
Baseada em texto 2,25
GUI 2,5
GUI complexa 3,0
3. Multiplicar as classes chaves por seus respectivos multiplicadores, para descobrir o número
de classes de suporte;
4. Multiplicar o número total de classes (chave + suporte) pelo número médio de unidades de
trabalho (dias-pessoa) por classe;
5. Determinar a quantidade de esforço estimada;
6. O resultado será a estimativa de tempo necessário para desenvolver o projeto.
2.2.2 Resultados
Aplicando as métricas de Lorenz e Kidd (LORENZ; KIDD, 1994), obtivemos:
1. O número de classes chave é 9.
2. Nosso sistema é baseado em uma GUI complexa, portanto, as classes chave possuem como
fator multiplicador 3,0.
3. O número de classes de suporte é 27.
Classes de suporte = Classes chave * Fator multiplicador => 9 x 3,0 = 27.
4. O total de classes projetadas para o sistema é 36.
Total de classes = Classes chave + Classes de suporte => 9 + 27 = 36.
5. Como esse é o primeiro projeto da equipe, que também não está familiarizada com as
ferramentas em que o software será desenvolvido, o número médio de unidades de trabalho
(dias-pessoa) por classe será de 20 dias-pessoa por classe.
6. A quantidade de esforço estimada é: 720 dias de trabalho.
Quantidade de esforço = Total de classes * Unidades de trabalho => 36 * 20 = 720.
7. Como a equipe para elaboração deste projeto é composta por 3 pessoas, a distribuição de
dias de trabalho por pessoa é: 240 dias de trabalho por pessoa.

11. Capítulo 2. Estimação do Projeto 10
Total de esforço estimado = Dias de trabalho por pessoa => 720 / 3 = 240.
Levando em consideração 22 dias úteis por mês e a quantidade de componentes envolvidos
no projeto, podemos considerar um tempo previsto de quase 11 meses para finalização do
projeto.
De acordo com a distribuição de esforços podemos definir os seguintes dados:
Tabela 3 – Estimativas de cada etapa do projeto
Etapa Estimativa Dias de trabalho
Planejamento 3% (240 * 3%) = 7 dias
Requisito-Análise-Desenho 40% (240 * 40%) = 96 dias
Geração de código 20% (240 * 20%) = 48 dias
Testes 37% (240 * 37%) = 89 dias
2.3 Recursos do projeto
2.3.1 Recursos humanos
A equipe deste projeto é composta por Alan Felix da Mota, Lucas dos Santos Aquino e
Mayk Willians Menezes. Todos são graduandos no Bacharelado em Sistemas de Informação da
Universidade Federal de Sergipe (UFS).
2.3.2 Recursos de Software
Os softwares a serem utilizados neste projeto são:
1. Eclipse: IDE utilizada na codificação do software.
2. Google Chrome: navegador utilizado para testar as funcionalidades do software.
3. Mozilla Firefox: navegador utilizado para testar as funcionalidades do software.
4. PostgreSQL: Sistema de gerenciamento de Banco de Dados
5. StarUML: Software de modelagem dos diagramas UML.
6. GitLab: Controle de versão
2.3.3 Recursos de Hardware
Os dispositvos de hardware a serem utilizados neste projeto são:
1. Notebooks: utilizados para a codificação e testes.

12. Capítulo 2. Estimação do Projeto 11
2.3.4 Recursos Bibliográficos
As referências bibliográficas utilizadas no projeto são:
1. PRESSMAN, Roger S. Engenharia de Software, 6ª edição, São Paulo, McGraw-Hill, 2006.
(PRESSMAN, 2006)
2. LORENZ, M.; KIDD, J. Object-oriented software metrics: a practical guide. Prentice-Hall,
Inc., Upper Saddle River, NJ, USA, 1994. (LORENZ; KIDD, 1994)
3. PRESSMAN, R.; MAXIM, B.Engenharia de Software: Uma abordagem proficional. 8. ed.
[S.l.]: McGraw Hill Brasil, 2016.
4. SOMMERVILLE, I.Engenharia de Software. [S.l.]: Pearson Education do Brasil, 2011

13. 12
3Análise e Gestão de Riscos
Análise e gestão de risco são uma série de passos que ajudam uma equipe de software a
entender e gerenciar a incerteza. Muitos problemas podem perturbar um projeto de software. O
risco é um problema em potencial – ele pode ocorrer ou não. Independentemente do resultado,
é aconselhável identificá-lo, avaliar sua probabilidade de ocorrência, estimar seu impacto e
estabelecer um plano de contingência caso o problema realmente ocorra (PRESSMAN; MAXIM,
2016).
Este capítulo apresenta a descrição dos riscos elencados para este projeto e suas propostas
de redução e contingência.
3.1 Riscos do projeto
Segundo Sommerville (2011), riscos de projeto são aqueles que afetam o cronograma ou
os recursos de um projeto. Os riscos de projeto identificam problemas potenciais de orçamento,
cronograma, pessoal (equipes e organização), recursos, clientes e requisitos e seu impacto sobre
o projeto de software (PRESSMAN; MAXIM, 2016).
Após reunião com a equipe, definimos uma lista dos possíveis riscos, categorizamos o
impacto e a probabilidade dos mesmos ocorrerem. Com isso, elaboramos a Tabela 4 ordenando
todos os riscos por impacto e probabilidade.

14. Capítulo 3. Análise e Gestão de Riscos 13
Tabela 4 – Tabela de riscos do MEA
Riscos Impacto Probabilidade
Não há uma abordagem proativa da SQA crítico 75%
Não há pessoas suficientes disponíveis crítico 65%
Equipe não recebeu treinamento necessário crítico 55%
Cliente não possui uma ideia clara dos objetivos crítico 15%
Cliente não participa das revisões crítico 12,5%
A equipe não possui as habilidades corretas moderado 87,5%
A tecnologia é nova para a organização moderado 77,5%
As melhores pessoas não estão disponíveis moderado 62,5%
A equipe não está comprometida por toda a duração moderado 52,5%
3.2 Redução e gestão do risco
A gestão de riscos e o plano de contingência consideram que os esforços de mitigação
do risco falharam e que o risco se tornou uma realidade (PRESSMAN; MAXIM, 2016).
É importante observar que as etapas de mitigação, monitoramento e gestão de risco
(RMMM, risk mitigation, monitoring, and management) acarretam custo adicional ao projeto
(PRESSMAN; MAXIM, 2016).
Para uma antecipação aos riscos, foram elencados planos para redução e contingência.
Neste caso, ocorrendo uma incidência, um plano de ação já estará traçado para contorna-lo
o mais breve possível. Dessa forma espera-se evitar a perda de recursos. Esses planos estão
elencados nas Tabelas que seguem:
Tabela 5 – Risco 1
Risco: Não há uma abordagem proativa de SQA.
Código: 001 Probabilidade: 75% Impacto: Crítico
Descrição: A equipe não monitora os processo de modo a garantir a qualidade do
Software que está sendo produzido
Estratégia de Redução: Adotar técnicas para medir a qualidade do Processo, tais como
CMMI ou MPS-Br.
Plano de Contingência: Capacitar os funcionários em boas práticas na construção de
Software, tais como:
1-Técnicas de revisão;
2- Testes de qualidade;
Pessoa Responsável: Lucas Aquino.
Status: Simulação completa.

15. Capítulo 3. Análise e Gestão de Riscos 14
Tabela 6 – Risco 2
Risco: Não há pessoas suficientes disponíveis.
Código: 002 Probabilidade: 65% Impacto: Crítico
Descrição: A quantidade de pessoas não é adequada ao tamanho do projeto.
Estratégia de Redução: Fazer uma melhor organização das tarefas de maneira a adequar
o trabalho a quantidade de pessoas disponíveis. Em paralelo a isso, realizar entrevistas de
emprego para cadastro de reserva, caso seja necessário contratar mais pessoas.
Plano de Contingência: Realizar contratação de pessoal, de acordo com as especifidades
das tarefas e as qualificações profissionais identificadas nas entrevistas realizadas
anteriormente.
Pessoa Responsável: Lucas Aquino
Status: Simulação completa.
Tabela 7 – Risco 3
Risco: Equipe não recebeu treinamento necessário.
Código: 003 Probabilidade: 55% Impacto: crítico
Descrição: Equipe não possui experiência com as ferramentas.
Estratégia de Redução: Realizar treinamentos prévios das ferramentas evitando
problemas no desenvolvimento.
Plano de contingência: Fazer a contratação de consultores que possa demonstrar os
atalhos que cada ferramenta possui de maneira a otimizar o trabalho.
Pessoa responsável: Alan Felix
Status: Em andamento.
Tabela 8 – Risco 4
Risco: Cliente não possui uma ideia clara dos objetivos.
Código: 004 Probabilidade: 15% Impacto: Crítico
Descrição: Cliente não tem certeza das funcionalidades que precisa no sistema.
Estratégia de Redução: Auxiliar o cliente, tirando dúvidas do mesmo e orientando-o
durante as entrevistas.
Plano de contingência: 1- Fazer mais entrevistas com o cliente;
2- Mostrar ao cliente soluções aplicadas a problemas semelhantes ao dele, objetivando
ajudá-lo a decidir quais funcionalidades deseja no produto de software.
Pessoa responsável: Alan Felix
Status: Simulação completa

16. Capítulo 3. Análise e Gestão de Riscos 15
Tabela 9 – Risco 5
Risco: Cliente não participa das revisões.
Código: 005 Probabilidade: 12,5% Impacto: crítico
Descrição: Cliente não possui tempo para participar das revisões e do andamento do
software
Estratégia de Redução: Agendar reuniões em horários flexíveis para o cliente
Plano de contingência: Enviar um resumo diário por e-mail e receber o feedback do
cliente. Adicionar o cliente ao projeto Trello, para que assim, ele possa acompanhar
diariamente o andamento do projeto.
Pessoa responsável: Alan Felix.
Status: Simulação completa.
Tabela 10 – Risco 6
Risco: A equipe não possui as habilidades corretas.
Código: 006 Probabilidade: 87,5% Impacto: moderado
Descrição: A equipe não possui as competências adequadas ao desenvolvimento do
projeto.
Estratégia de Redução: Realizar treinamentos periódicos para atualizar a equipe.
Plano de contingência: Realizar entregas incrementais, levando em conta a complexidade
do software. Realizar um treinamento emergencial e acelerar a entrega.
Pessoa responsável: Lucas Aquino
Status: Simulação completa.
Tabela 11 – Risco 7
Risco: A tecnologia é nova para a organização
Código: 007 Probabilidade: 77,5% Impacto: moderado
Descrição: A tecnologia proposta para o desenvolvimento do projeto é nova para a
organização.
Estratégia de Redução: Promover treinamentos sobre as novas tecnologias necessárias
ao desenvolvimento do projeto.
Plano de contingência: Promover treinamentos intensivos ou adequar o projeto a uma
tecnologia conhecida pela organização.
Pessoa responsável: Alan Felix e Mayk Willians.
Status: Simulação completa.
Tabela 12 – Risco 8
Risco: As melhores pessoas não estão disponíveis.
Código: 008 Probabilidade: 62,5% Impacto: moderado
Descrição: A pessoa mais indicada para um determinada atividade pode não estar
disponível quando for necessário executá-la.
Estratégia de Redução: Planejar para que as atividades sejam realizadas, quando o
membro da equipe adequado àquela tarefa esteja disponível.
Plano de contingência: Possuir um membro substituto para executar cada tarefa.
Pessoa responsável: Lucas Aquino
Status: Simulação completa.

17. Capítulo 3. Análise e Gestão de Riscos 16
Tabela 13 – Risco 9
Risco: A equipe não está comprometida por toda a duração.
Código: 009 Probabilidade: 52,5% Impacto: moderado
Descrição:Alguns membros da equipe podem não estar disponíveis durante toda a
duração do projeto.
Estratégia de Redução: Planejar para que os membros da equipe que tiveram atuação
temporária desenvolvam as atividades necessárias no tempo estipulado.
Plano de contingência: Capacitar outro membro nas atividades do membro temporário.
Pessoa responsável: Lucas Aquino
Status: Simulação completa.

18. 17
4Planejamento Temporal
O planejamento temporal é uma das partes mais importantes do projeto. Aqui, conse-
guimos identificar todas as tarefas do projeto de software, além de mostrar toda a duração do
mesmo, etapa por etapa, para uma melhor monitoria por parte do Gerente.
4.1 Conjunto de tarefas do projeto
O conjunto de tarefas definidas para realizar o processo de desenvolvimento do MEA
estão dispostas na Tabela 14, bem como o tempo estimado para a conclusão de cada uma delas.
A definição do tempo estimado para realização das atividades foi de 240 dias úteis, onde 3% do
esforço do projeto foi destinado à atividade de Planejamento, 40% foi destinado ao Levantamento,
Análise e Especificação de Requisitos, 20% foi destinado à Codificação do software e 37% para
a realização de Testes.
Tabela 14 – Tempo estimado de cada tarefa macro do projeto
Tarefas Porcentagem (%) Tempo - Dias de trabalho
Planejamento 3% 7 dias
Requisito-Análise-Desenho 40% 96 dias
Codificação 20% 48 dias
Testes 37% 89 dias
4.2 Diagrama de Gantt
A Figura 1 traz o detalhamento de todas as tarefas que serão realizadas durante o
desenvolvimento do software em um gráfico de Gantt.

19. Capítulo 4. Planejamento Temporal 18
Figura 1 – Diagrama de Gantt

20. 19
5Organização da Equipe
Nesta seção iremos apresentar a distribuição e a organização das pessoas diretamente
envolvidas no projeto, como também suas respectivas funções e ferramentas utilizadas para a
comunicação entre os membros.
5.1 Estrutura da equipe
A equipe é formada por: Lucas dos Santos Aquino, Alan Felix da Mota e Mayk Willians
Santos Menezes. A divisão de funções entre cada membro da equipe está estruturada conforme a
Tabela 15 logo abaixo:

21. Capítulo 5. Organização da Equipe 20
Tabela 15 – Divisão de Funções
Responsável Função
Descrição
da função
Lucas
dos Santos Aquino
Gerente
do Projeto
Atribuir aos membros da
equipe as funções de cada um,
repassando os prazos e também
orçamentos; cobrar de cada membro
da equipe para que a função designada
esteja sendo realizada com sucesso.
Alan Felix da Mota e
Mayk Willians
Santos Menezes
Analista
de Sistemas
Atuar na parte de planejamento,
levantamento de requisitos,
como também acompanhar e
gerir a evolução do produto
de software
Mayk Willians
Santos Menezes
Programador
Implementar
o código do sistema
Alan
Felix da Mota
Administrador
de Banco de Dados
Gerir, instalar, configurar,
atualizar e monitorar o
sistema de banco de dados
Lucas
dos Santos Aquino
Analista
de Testes
Realizar testes no sistema
afim de garantir a qualidade
do produto de software
5.2 Mecanismos de comunicação
Para manter a comunicação remota entre os membros da equipe foi utilizado o aplicativo
de mensagens instantâneas Whatsapp que serviu como meio de comunicação para definir e dividir
as tarefas de cada participante da equipe, como também para discutir o andamento do projeto
e expor as dificuldades na execução das tarefas atribuídas a cada um. Também foi utilizado o
e-mail para troca de informações, como documentos e artigos relacionados ao assunto abordado
no projeto.
Para a auxiliar na escrita deste documento foi utilizada a ferramenta web ShareLaTeX,
que provê funcionalidades que ajudam na confecção de documentos no formato PDF. Também
utilizamos a plataforma Google Drive, que serviu como repositório dos documentos relacionados
a esse projeto.
Para a comunicação acerca de assuntos mais críticos, como tomadas de decisão impor-
tantes e dúvidas mais complexas, realizamos reuniões presenciais na Universidade Federal de
Sergipe. Essas reuniões serviram também para termos um maior controle de qualidade durante
todas as fases do projeto, assim como para cada membro da equipe apresentar novas ideias e dar
sugestões de melhoria ao projeto.

22. Capítulo 5. Organização da Equipe 21
5.3 Uso do Edu-blog como ferramenta de apoio
A ferramenta de apoio Edu Blog teve uma grande contribuição para o bom andamento do
projeto, assim como e toda a disciplina de Gerência de Projetos. No blog, todos os membros da
equipe realizaram postagens acerca do assunto abordado durante toda a disciplina, melhorando
assim a comunicação e o compartilhamento das informações entre os membros da equipe e entre
os demais alunos da disciplina.
Principais atividades realizadas por meio da ferramenta de apoio Edu Blog durante a
disciplina:
• Compartilhamento de novidades e tendências acerca da disciplina como também informa-
ções sobre o projeto;
• Troca de informações entre membros de equipes distintas;
• Disseminação do conhecimento;
• Realização de comentários em postagens de outras equipes, apontando pontos positivos e
negativos, como também assuntos complementares

23. 22
6Precauções a Serem Tomadas para Assegu-
rar e Controlar a Qualidade do Produto de
Software
Uma das precauções a que foi tomada foi diretamente com o cliente, para que os
requisitos do software estivessem todos de acordo com o que o cliente desejava. Para isso
realizamos reuniões com o cliente juntamente com toda a equipe, com o intuito de prover mais
eficiência e eficácia na comunicação.
Outra precaução tomada foi a produção adequada de toda a documentação desde o
planejamento até os testes no software. A cada alteração durante o projeto a documentação
também era modificada, garantindo assim que ela estivesse sempre atualizada.
Reuniões entre os membros da equipe, inclusive com o cliente eram frequentes. Essas reu-
niões serviram para discutir o andamento do projeto, dificuldades encontradas e principalmente
para ouvir o cliente e verificar se o sistema estava de acordo com o que ele desejava.
Também para garantir a qualidade do produto de software, mantivemos o foco nos atribu-
tos de qualidade: Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Manutenibilidade e
Portabilidade. Definidos pela norma ISO/IEC 9126 para qualidade de produto de software. Esta
ISO/IEC 9126 define um conjunto de parâmetros com o objetivo de padronizar a avaliação da
qualidade de software.

24. 23
Referências
LORENZ, M.; KIDD, J. Object-oriented software metrics: a practical guide. [S.l.]: Prentice-Hall,
Inc., 1994. Citado 3 vezes nas páginas 8, 9 e 11.
PRESSMAN, R.; MAXIM, B. Engenharia de Software: Uma abordagem proficional. 8. ed.
[S.l.]: McGraw Hill Brasil, 2016. Citado 2 vezes nas páginas 12 e 13.
PRESSMAN, R. S. Engenharia de Software. [S.l.]: McGraw-Hill, 2006. v. 6ª Edição. Citado na
página 11.
SOMMERVILLE, I. Engenharia de Software. [S.l.]: Pearson Education do Brasil, 2011. Citado
na página 12.

25. 24
ANEXO A – Diagrama de classes de
projeto