SlideShare uma empresa Scribd logo
1 de 25
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
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
Lista de ilustrações
Figura 1 – Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
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
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
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
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.
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.
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:
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.
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.
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
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.
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.
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
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.
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.
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.
Capítulo 4. Planejamento Temporal 18
Figura 1 – Diagrama de Gantt
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:
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.
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
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.
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.
24
ANEXO A – Diagrama de classes de
projeto

Mais conteúdo relacionado

Mais procurados

Marcos_Antonio_V_Oliveira_TCC_Apr_Final
Marcos_Antonio_V_Oliveira_TCC_Apr_FinalMarcos_Antonio_V_Oliveira_TCC_Apr_Final
Marcos_Antonio_V_Oliveira_TCC_Apr_FinalMarcos Ventura
 
Apostila cdtc dotproject
Apostila cdtc dotprojectApostila cdtc dotproject
Apostila cdtc dotprojectTiago
 
Javascript
JavascriptJavascript
JavascriptTiago
 
Trabalho de Graduação - Desenvolvimento de Ferramenta Móvel de CRM Social
Trabalho de Graduação - Desenvolvimento de Ferramenta Móvel de CRM SocialTrabalho de Graduação - Desenvolvimento de Ferramenta Móvel de CRM Social
Trabalho de Graduação - Desenvolvimento de Ferramenta Móvel de CRM SocialJuliana Fideles
 
Planejamento em desenvolvimento_de_sistemas
Planejamento em desenvolvimento_de_sistemasPlanejamento em desenvolvimento_de_sistemas
Planejamento em desenvolvimento_de_sistemasTiago
 
Ruby on rails
Ruby on railsRuby on rails
Ruby on railsTiago
 
Manual Minitab pela Saldit Software
Manual Minitab pela Saldit SoftwareManual Minitab pela Saldit Software
Manual Minitab pela Saldit SoftwareSaldit Software
 
Programacao cpp
Programacao cppProgramacao cpp
Programacao cppTiago
 
Wx python
Wx pythonWx python
Wx pythonTiago
 
Squid guard
Squid guardSquid guard
Squid guardTiago
 
Interface gráfico para gestão de uma agência de viagens
Interface gráfico para gestão de uma agência de viagensInterface gráfico para gestão de uma agência de viagens
Interface gráfico para gestão de uma agência de viagenspjclima
 
X dialog
X dialogX dialog
X dialogTiago
 

Mais procurados (20)

Marcos_Antonio_V_Oliveira_TCC_Apr_Final
Marcos_Antonio_V_Oliveira_TCC_Apr_FinalMarcos_Antonio_V_Oliveira_TCC_Apr_Final
Marcos_Antonio_V_Oliveira_TCC_Apr_Final
 
Horde
HordeHorde
Horde
 
Access
AccessAccess
Access
 
Apostila cdtc dotproject
Apostila cdtc dotprojectApostila cdtc dotproject
Apostila cdtc dotproject
 
Javascript
JavascriptJavascript
Javascript
 
Postgre Sql
Postgre SqlPostgre Sql
Postgre Sql
 
Uml
UmlUml
Uml
 
Sql
SqlSql
Sql
 
Trabalho de Graduação - Desenvolvimento de Ferramenta Móvel de CRM Social
Trabalho de Graduação - Desenvolvimento de Ferramenta Móvel de CRM SocialTrabalho de Graduação - Desenvolvimento de Ferramenta Móvel de CRM Social
Trabalho de Graduação - Desenvolvimento de Ferramenta Móvel de CRM Social
 
Planejamento em desenvolvimento_de_sistemas
Planejamento em desenvolvimento_de_sistemasPlanejamento em desenvolvimento_de_sistemas
Planejamento em desenvolvimento_de_sistemas
 
Vim
VimVim
Vim
 
Zope
ZopeZope
Zope
 
Ruby on rails
Ruby on railsRuby on rails
Ruby on rails
 
Manual Minitab pela Saldit Software
Manual Minitab pela Saldit SoftwareManual Minitab pela Saldit Software
Manual Minitab pela Saldit Software
 
Programacao cpp
Programacao cppProgramacao cpp
Programacao cpp
 
Wx python
Wx pythonWx python
Wx python
 
Squid guard
Squid guardSquid guard
Squid guard
 
Interface gráfico para gestão de uma agência de viagens
Interface gráfico para gestão de uma agência de viagensInterface gráfico para gestão de uma agência de viagens
Interface gráfico para gestão de uma agência de viagens
 
X dialog
X dialogX dialog
X dialog
 
TG KickGames
TG KickGamesTG KickGames
TG KickGames
 

Semelhante a Plano de projeto de software para o sistema MEA - monitoraemto de eventos adversos

Plano de Projeto de Software - SIUR
Plano de Projeto de Software - SIURPlano de Projeto de Software - SIUR
Plano de Projeto de Software - SIUREdgar Lima
 
Plano de Projeto de Software
Plano de Projeto de SoftwarePlano de Projeto de Software
Plano de Projeto de SoftwareMatheus Mendonça
 
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...JADSON SANTOS
 
Quanta
QuantaQuanta
QuantaTiago
 
Plano de Projeto - Gerencia de Projetos
Plano de Projeto - Gerencia de ProjetosPlano de Projeto - Gerencia de Projetos
Plano de Projeto - Gerencia de ProjetosHelder Filho
 
Linguagem c
Linguagem cLinguagem c
Linguagem cTiago
 
Planejamento_e_Controle_de_Obras_Residen.pdf
Planejamento_e_Controle_de_Obras_Residen.pdfPlanejamento_e_Controle_de_Obras_Residen.pdf
Planejamento_e_Controle_de_Obras_Residen.pdfJenilsonPires1
 
Um estudo de caso para a avaliação do Scrum sob a Óptica do MPS.BR Nível G
Um estudo de caso para a avaliação do Scrum sob a Óptica do MPS.BR Nível GUm estudo de caso para a avaliação do Scrum sob a Óptica do MPS.BR Nível G
Um estudo de caso para a avaliação do Scrum sob a Óptica do MPS.BR Nível GMarcos Vinícius Godinho
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWInstituto Federal de Sergipe
 
Plano de projeto de software
Plano de projeto de softwarePlano de projeto de software
Plano de projeto de softwareSigelman Araujo
 
Plano de Projeto de Software NutriBR
Plano de Projeto de Software NutriBRPlano de Projeto de Software NutriBR
Plano de Projeto de Software NutriBRaffonsosouza
 

Semelhante a Plano de projeto de software para o sistema MEA - monitoraemto de eventos adversos (20)

Plano de Projeto de Software - SIUR
Plano de Projeto de Software - SIURPlano de Projeto de Software - SIUR
Plano de Projeto de Software - SIUR
 
Relatório de fim de curso
Relatório de fim de cursoRelatório de fim de curso
Relatório de fim de curso
 
Sql
SqlSql
Sql
 
Plano de Projeto de Software
Plano de Projeto de SoftwarePlano de Projeto de Software
Plano de Projeto de Software
 
Plano de projeto gp mateus schuch
Plano de projeto gp mateus schuchPlano de projeto gp mateus schuch
Plano de projeto gp mateus schuch
 
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...
 
Quanta
QuantaQuanta
Quanta
 
Plano de Projeto - Gerencia de Projetos
Plano de Projeto - Gerencia de ProjetosPlano de Projeto - Gerencia de Projetos
Plano de Projeto - Gerencia de Projetos
 
Linguagem c
Linguagem cLinguagem c
Linguagem c
 
monografia_andre_paro
monografia_andre_paromonografia_andre_paro
monografia_andre_paro
 
Planejamento_e_Controle_de_Obras_Residen.pdf
Planejamento_e_Controle_de_Obras_Residen.pdfPlanejamento_e_Controle_de_Obras_Residen.pdf
Planejamento_e_Controle_de_Obras_Residen.pdf
 
Um estudo de caso para a avaliação do Scrum sob a Óptica do MPS.BR Nível G
Um estudo de caso para a avaliação do Scrum sob a Óptica do MPS.BR Nível GUm estudo de caso para a avaliação do Scrum sob a Óptica do MPS.BR Nível G
Um estudo de caso para a avaliação do Scrum sob a Óptica do MPS.BR Nível G
 
Plano de Projeto SGS
Plano de Projeto SGSPlano de Projeto SGS
Plano de Projeto SGS
 
Condo master
Condo masterCondo master
Condo master
 
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SWPLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
 
Plano de projeto de software
Plano de projeto de softwarePlano de projeto de software
Plano de projeto de software
 
Plano deprojeto grupo1
Plano deprojeto grupo1Plano deprojeto grupo1
Plano deprojeto grupo1
 
TCC Aporano Play'ed SCRUM'ces
TCC Aporano Play'ed SCRUM'cesTCC Aporano Play'ed SCRUM'ces
TCC Aporano Play'ed SCRUM'ces
 
Plano de Projeto de Software NutriBR
Plano de Projeto de Software NutriBRPlano de Projeto de Software NutriBR
Plano de Projeto de Software NutriBR
 
Plano deprojeto grupo1
Plano deprojeto grupo1Plano deprojeto grupo1
Plano deprojeto grupo1
 

Plano de projeto de software para o sistema MEA - monitoraemto de eventos adversos

  • 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