Plano de projeto: Bichos do Campus na Web

UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Disciplina: Gerência de Projetos
Professor: Dr. Rogério Patrício Chagas do Nascimento
Bichos do Campus na Web
Plano de Projeto de Software
Álvaro dos Santos Reis
Francisco Luan dos Santos
Jorge Roberto de Carvalho Júnior
Matheus Gustavo Calazans de Aquino
Silvaneide Vieira dos Santos
Departamento de Computação/UFS
São Cristóvão – Sergipe
2020

UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Álvaro dos Santos Reis
Francisco Luan dos Santos
Jorge Roberto de Carvalho Júnior
Matheus Gustavo Calazans de Aquino
Silvaneide Vieira dos Santos
Bichos do Campus na Web
Plano de Projeto de Software submetido como requi-
sito parcial para a conclusão da disciplina de Gerência
de Projetos do Departamento de Computação da Uni-
versidade Federal de Sergipe.
Professor: Dr. Rogério Patrício Chagas do Nascimento
São Cristóvão – Sergipe
2020

Lista de ilustrações
Figura 1 – Diagrama de Caso de Uso do Sistema . . . . . . . . . . . . . . . . . . . . . 6
Figura 2 – Diagrama de Classes do Projeto . . . . . . . . . . . . . . . . . . . . . . . . 10
Figura 3 – Diagrama de Gantt do Sistema . . . . . . . . . . . . . . . . . . . . . . . . 18

Lista de tabelas
Tabela 1 – Tabela de multiplicador do projeto segundo Lorenz & Kidd . . . . . . . . . 9
Tabela 2 – Principais Riscos do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Tabela 3 – Redução e Contingência de Riscos - 001 . . . . . . . . . . . . . . . . . . . 13
Tabela 13 – Tabela estrutural da equipe . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Sumário
1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Âmbito do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
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ções do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 Dados Históricos Utilizados para as 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 Recursos Humanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2 Recursos de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.3 Recursos de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Análise e Gestão de Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Riscos do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Redução e Contingência de Riscos . . . . . . . . . . . . . . . . . . . . . . . . 12
4 Planejamento Temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1 Conjunto de Tarefas do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2 Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5 Organização do Pessoal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1 Estrutura da Equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Mecanismos de Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3 Uso do Edu-blog como Ferramenta de Apoio . . . . . . . . . . . . . . . . . . 19
6 Precauções Tomadas para Assegurar e Controlar a Qualidade do Produto de
Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5
1Introdução
Bichos do Campus é um programa que tem o objetivo cuidar dos animais que são
abandonados ou nascidos nos campus da Universidade Federal de Sergipe (UFS). Uma das
responsabilidades do Bichos do Campus é preparar alguns desses animais para serem a adotados,
porem a única forma de divulgação que eles usam é por meio de rede social, o que acaba sendo
pouco eﬁciente e por isso o projeto Bichos do Campus na Web foi criado.
O Bichos do Campus na Web foi criado com o objetivo de melhorar a visibilidade de
animais disponíveis para adoção e também otimizar o processo de adoção.
Após o levantamento de requisitos com as pessoas envolvidas no gerenciamento e
administração do Bichos do Campus, entendamos que o melhor jeito de resolver as necessidades
deles eram através de uma aplicação web.
1.1 Âmbito do Projeto
O software consiste de uma aplicação web onde serão cadastrados os animais disponíveis
para a adoção e registraria todo pedido de adoção.
Cada cadastro de animais disponibilizaria várias informações sobre o animal como raça,
idade, sexo e até mesmo se ele já foi castrado. Seria permitido também a adição de múltiplas
fotos do animal.
Quando alguém queira adotar algum animal, essa pessoa teria que preencher um for-
mulário com alguns dados pessoais e a administração do Bichos do Campus seria informada
desse formulário e entraria em contato com esse pessoal. Por normas do Bichos do Campus toda
adoção só pode ser aprovada após varias ações que só podem ser realizadas pessoalmente, logo a
adoção não poderia ser completamente feita online.

Capítulo 1. Introdução 6
1.2 Funções Principais do Produto de Software
Na Figura 1 as principais funções do sistema são descritas usando o diagrama de caso de
uso. Neste diagrama vemos 4 atores, eles são:
• Pessoa da ONG: pessoa que trabalha para o Bichos do Campus, responsável pelas adoções;
• ADM do Sistema: coordenador do projeto do Bichos do Campus;
• Pessoa Adotante: qualquer que acessar o sistema sem logar;
• Sistema: ações automáticas do sistema.
Figura 1 – Diagrama de Caso de Uso do Sistema
1.3 Requisitos Comportamentais ou de Performance
Consideramos os seguintes requisitos não-funcionais para o projeto do Bichos do Campus
na Web:
• Usabilidade:
– O sistema precisa ter uma interface simples e direta;

Capítulo 1. Introdução 7
– O usuário deve poder fazer uma requisição para adotar um animal em poucos passos.
• Conﬁabilidade:
– O sistema não pode permitir que pessoas não registradas vejam informações restritas;
– O sistema não pode permitir que pessoas não logadas fação qualquer ação no sistema
além de requisição de adoção.
• Disponibilidade:
– O sistema precisa está disponível vinte quatro horas por dia e sete dias por semana;
• Segurança:
– O sistema deve prover autentiﬁcação ao usuário de acordo com o seu nível de acesso.
1.4 Gestão e Restrições Técnicas
O software será desenvolvido na linguagem PHP, pois é a linguagem que o time é mais
familiar. Foi decidido também utilizar o framework Laravel para agilizar e facilitar desenvolvi-
mento do software.
A metodologia de desenvolvimento será utilizada para o projeto é a Ágil. Esta foi
escolhida, pois o time precisará entregar partes do software para validação com o cliente.

8
2Estimações do Projeto
Neste item, contém a descrição de estimativa de tempo, custo e esforço desenvolvido
pelo projeto.
2.1 Dados Históricos Utilizados para as Estimações
Como sendo primeiro projeto da equipe, não há histórico para estimações de tempo,
custo ou esforço anteriormente realizados.
2.2 Técnicas de Estimação e Resultados
Para estimação de tempo foi utilizada a técnica de Lorenz & Kidd a qual utiliza-se
da orientação a objetos, adotada pela Lacertae Software. Baseada na divisão de classes por
categorias (tempo, herança, características internas e avaliação de coesão) estimando-se todo
projeto.
2.2.1 Técnica de Estimação
As métricas utilizadas para estimação de tempo do projeto foram o conjunto de técnicas
de mensuração de Lorenz & Kidd a qual utiliza o número de classes chave e classes suporte para
determinar o tempo necessário para o desenvolvimento do projeto.
Para realizar essa análise, foi preciso definir a quantidade de classes existentes no projeto.
Logo após, definimos como seria a aplicação. O número de classes chave (classes domínio
determinada pela regra de negócio na análise de requisitos) aponta o esforço definido no projeto
e a quantidade de classes reutilizáveis na aplicação. O número de classes suporte (classes apoio)
é apontado de acordo com a aplicação, ou seja, o número de classes chave vezes o multiplicador

Capítulo 2. Estimações do Projeto 9
da aplicação. A Tabela 1 determina o padrão de cada multiplicador usando esta técnica de
estimação.
Interface Multiplicador
não gráﬁca 2
baseada em texto 2,25
GUI 2,5
GUI complexa 3
Tabela 1 – Tabela de multiplicador do projeto segundo Lorenz & Kidd
O multiplicador do projeto (para classe suporte) usado nessa técnica de acordo com
nosso caso, foi deﬁnido a interface GUI (Graphical User Interface) para que o usuário consiga
obter um visual simples e exercer suas tarefas facilmente sem necessidade de conhecimento
profundo na área de marcação de consultas ou de tecnologia.
Sendo assim, temos o cálculo do número de classes suporte dado por:
n° de classes suporte = n° de classes chaves×multiplicador
Por sugestão da técnica de Lorenz & Kidd (sugere entre 15 e 20 dias-pessoa por classe)
determinamos 19 dias-pessoa por classe (próximo do máximo). Nessa técnica, usa-se todos os
dados anteriormente explicados. Determinamos a estimativa com a soma também das classes
(classes chave somado com as classes suporte) e multiplicando-as pelo número de dias-pessoa
determinado.
(n° de classes suporte+n° de classes chaves)×dias-pessoa
Nesse contexto temos um prazo de tempo estipulado para que a equipe conclua o projeto
(não havendo alterações nos itens necessários para o cálculo).
2.2.2 Resultados
Conforme o diagrama de classe mostrado na Figura 2 determinamos os resultados da
estimação de período gasto no projeto.
• Classes chave: Adotante, animal, raça e local;
• Tipo das classes suporte: interface GUI simples. Sendo assim, como dito anteriormente,
seu multiplicador será 2,5;
• Classes suporte: 4 (número de classes chave) x 2,5 (multiplicador) = 10 (classes suporte);
• Total de classes trabalhadas no projeto: 4 (classes chave) + 10 (classes suporte) = 14
(classes do projeto);

Figura 2 – Diagrama de Classes do Projeto
• Número médio de unidades de trabalho: 19 dias-pessoa;
• Tempo total previsto pela estimação: 14 (classes) x 19 (dias-pessoa) = 266 dias (de 8 horas)
para construção das classes.
Como a equipe possui 5 integrantes então o período por pessoa ﬁca: 266/5 = 53,2 dias
úteis (por pessoa da equipe). Dividindo 53,2 por 22 (número de dias úteis em um mês) temos 2
meses, 9 dias e 2 horas de projeto pra toda a equipe.

2.3 Recursos do Projeto
Neste item serão descritos os recursos utilizados pelo projeto os quais são: humanos, de
software e de hardware.
2.3.1 Recursos Humanos
Com auxílio de recurso humano, ou seja, proﬁssionais da área, os quais foram responsá-
veis pelo desenvolvimento do projeto contendo:
• 01 Gerente de Projetos
• 01 Analistas de Sistemas
• 01 Analista de Riscos
• 02 Desenvolvedores
• 01 Testador
A equipe possui 5 integrantes e por isso tiveram proﬁssionais que atuaram no projeto em
mais de uma área.
2.3.2 Recursos de Software
O projeto irá utilizar os seguintes recursos de software:
• MariaDB: banco de dados do sistema;
• Visual Studio Code: IDE para desenvolvimento do projeto;
• GitHub: ferramenta de controle de versão do projeto;
• StarUML: ambiente modelador de diagramas UML;
• Google Docs e Microsoft Word: processadores de texto usados para auxiliar na elabora-
ção da documentação;
• Mozilla Firefox: navegador web.
2.3.3 Recursos de Hardware
O projeto irá utilizar os seguintes recursos de hardware:
• 5 computadores, sendo um computador para membro do grupo;
• 1 servidor para hospedar o projeto.

12
3Análise e Gestão de Riscos
Nesta seção apresenta a descrição e os planos de redução e contingência dos riscos
identificados.
3.1 Riscos do Projeto
A Tabela 2 foi escrita a partir de um brainstorming, feito pelos membros do grupo, para
identificar os principais ricos do projeto.
Risco Impacto Probabilidade
O cliente não possui uma ideia clara sobre os requisitos do projeto Catastrófico 70%
O cliente não tem tempo para fazer reuniões Catastrófico 40%
A equipe não conseguiu se adaptar à nova tecnologia Catastrófico 35%
A equipe não possui as habilidades certas para concluir o projeto Catastrófico 30%
A projeto está com falta de pessoal Catastrófico 20%
Mudança de pessoal antes do projeto acabar Crítico 85%
O cliente não conseguir se adaptar ao uso do software Crítico 50%
O pessoal não recebeu o devido treinamento Crítico 45%
Não conseguir um local gratuito para hospedar o projeto Crítico 30%
O projeto não possui uma deadline razoável Crítico 15%
Tabela 2 – Principais Riscos do Projeto
3.2 Redução e Contingência de Riscos
Com o objetivo de antecipar e minimizar os problemas decorrentes dos riscos listados na
Tabela 2, foram traçados os Planos para Redução, Supervisão e Contingência de Riscos. Esses
planos estão expostos da Tabela 3 até a Tabela 12.

Capítulo 3. Análise e Gestão de Riscos 13
Risco: O cliente não possui uma ideia clara sobre os requisitos do projeto.
Código: 001 Impacto: Catastróﬁco Probabilidade: 70%
Descrição: O cliente não consegue enxergar suas necessidades, nem sabe como resolvê-las.
Estratégia de redução: Fazer reuniões não somente com o cliente, mas com o máximo
de stakeholders possíveis; fazer validações de pequenas partes do software.
Plano de contingência: Refazer o levantamento de requisitos utilizar técnicas como
brainstorm, workshops e entrevistas.
Pessoa responsável: Matheus Aquino.
Status: Simulação incompleta
Tabela 3 – Redução e Contingência de Riscos - 001
Risco: O cliente não tem tempo para fazer reuniões.
Descrição: O cliente não possui tempo para as reuniões de desenvolvimento ágil.
Estratégia de redução: Elaborar um resumo com os tópicos a serem discutidos na reunião,
disponibilizar uma ferramenta de comunicação para o cliente se comunicar com o gerente
projeto e informar suas duvidas e opiniões.
Plano de contingência: Mudar o horário das reuniões; disponibilizar um documento com
um resumo do projeto para o cliente; procurar associados do cliente que compreendam do
projeto.
Pessoa responsável: Álvaro Reis.
Status: Simulação incompleta.
Risco: A equipe não conseguiu se adaptar à nova tecnologia.
Descrição: A equipe não conseguiu se adaptar à nova tecnologia.
Estratégia de redução: Fazer programação em duplas; ter reuniões periodicamente para
duvidas e desaﬁos.
Plano de contingência: Explorar a possibilidade de troca de tecnologia; reorganizar as
atividade de cada um do time.
Pessoa responsável: Matheus Aquino.
Status: Simulação incompleta
Risco: A equipe não possui as habilidades certas para concluir o projeto.
Descrição: A equipe não possui habilidades para concluir o projeto.
Estratégia de redução: Treinar a equipe para prover a conclusão do projeto; disponibilizar
manual para ferramenta de gerencia do projeto; manter a comunicação da equipe.
Plano de contingência: Contratar pessoa(s) com a habilidade que a equipe precisa; nego-
ciar com o cliente uma mudança no escopo do projeto.
Pessoa responsável: Francisco L. dos Santos.

Risco: A projeto está com falta de pessoal.
Descrição: Não há um número suficiente de pessoas na equipe.
Estratégia de redução: Negociar com o cliente o prazo ou quais funcionalidades são
criticas para serem entregues até o prazo.
Plano de contingência: Estender o prazo do projeto; negociar com o cliente o escopo do
projeto, a fim de não comprometer a usabilidade mínima do projeto de software.
Pessoa responsável: Álvaro Reis.
Risco: Mudança de pessoal antes do projeto acabar.
Código: 006 Impacto: Crítico Probabilidade: 85%
Descrição: Possibilidade de membros da equipe abandonar o projeto antes do termino.
Estratégia de redução: Negociar com o membro da equipe possibilidade de ficar; ter lista
de pessoal com a formação necessária para assumir a vaga; negocia aumento de prazo com
o cliente.
Plano de contingência: Contratar novo funcionário.
Pessoa responsável: Francisco L. dos Santos.
Risco: O cliente não conseguir se adaptar ao uso do software.
Descrição: Funcionalidades diferentes do padrão utilizado anteriormente.
Estratégia de redução: Treinamento e capacitação do cliente para promover melhor
adaptação do mesmo na utilização do software, e se possível disponibilizar manual básico
para os procedimentos mais importantes ou comuns do software.
Plano de contingência: Mostrar para o cliente vantagens de quando estiver adaptado
a nova tecnologia, estabelecer métricas de aprendizagem mostrando que ainda dá para
aprender utilizá-lo. Repassar o que ele não aprendeu.
Pessoa responsável: Silvaneide V. dos Santos.

Risco: O pessoal não recebeu o devido treinamento
Descrição: Falta de treinamento de algumas funcionalidades do software.
Estratégia de redução: Negociar com cliente outro treinamento oferecendo uma bonifica-
ção ou desconto em alguma funcionalidade para que desperte o interesse do mesmo na
utilização do software.
Plano de contingência: Disponibilizar treinamento online da tecnologia de forma mais
simples e direta para o cliente (blended learning), fazendo com que ele assista e avance
quando quiser, sem se preocupar.
Pessoa responsável: Silvaneide V. dos Santos.
Risco: Não conseguir um local gratuito para hospedar o projeto.
Descrição: Possibilidade de não conseguir um local gratuito para hospedar a aplicação.
Estratégia de redução: Solicitar colegas da comunidade sergipana de desenvolvedores
para que, inicialmente, hospedem o projeto em seu servidores enquanto resolvemos o
problema ou requisitar à STI que a aplicação possa ser hospedada nos servidores da UFS.
Plano de contingência: Pedir ao cliente para contratar um serviço.
Pessoa responsável: Jorge R. de Carvalho Júnior.
Risco: O projeto não possui uma deadline razoável.
Descrição: Possibilidade do prazo de entrega não ser suficiente para o desenvolvimento
do produto.
Estratégia de redução: Analisar o escopo do projeto e se a quantidade de desenvolvedores
é suficiente, fazer programação em pares para adiantar o projeto e reuniões diária para
verificar andamento do projeto.
Plano de contingência: Conversar com o cliente para reduzir escopo do projeto, estender
o prazo de entrega ou contratar mais desenvolvedores.
Pessoa responsável: Jorge R. de Carvalho Júnior.

16
4Planejamento Temporal
4.1 Conjunto de Tarefas do Projeto
Como calculado na Seção 2.2 deste documento, a estimação de Tempo do projeto foi de
53,2 dias por pessoa da equipe no total, o tempo estimado foi dividido em 40%,20%,40% ou
4:2:4, onde 20% ou 18 dias para atividades de planejamento e especiﬁcação do projeto, 20%
ou 10 dias para atividades de desenvolvimento e 40% ou 18 dias para atividades de ﬁnalização
do projeto de software. A fase de desenvolvimento foi dividida em 2 sprints. Na fase inicial do
projeto foram utilizados 11 dias para atividades de planejamento e projeto.
A fase de desenvolvimento foi dividida em 2 sprints:
• Sprint 1
– Scrum Master: Jorge Roberto de Carvalho Júnior;
– Time de Desenvolvimento:
* Álvaro dos Santos Reis;
* Francisco Luan dos Santos;
* Matheus Gustavo Calazans de Aquino;
* Silvaneide Vieira dos Santos.
• Sprint 2
– Scrum Master: Matheus Gustavo Calazans de Aquino;
– Time de Desenvolvimento:
* Álvaro dos Santos Reis;
* Francisco Luan dos Santos;

Capítulo 4. Planejamento Temporal 17
* Matheus Gustavo Calazans de Aquino;
* Silvaneide Vieira dos Santos.
Também foram reservados na ﬁnalização 6 dias para atividades de testes, homologação
do produto ﬁnal e implantação.
4.2 Diagrama de Gantt
O objetivo do diagrama de Gantt é disponibilizar uma visualização do planejamento do
projeto levando em consideração prazos e atribuições de forma visual e de fácil compreensão.
O desenvolvimento do diagrama de Gantt do projeto usou como base a metodologia
Scrum, a mesma metodologia utilizada no desenvolvimento do projeto de software.
A Figura 3 mostra o diagrama de Gantt, sua linha do tempo se inicia em 02/03/20 e se
encerra em 24/04/20.

Capítulo 4. Planejamento Temporal 18
Figura3–DiagramadeGanttdoSistema

19
5Organização do Pessoal
Neste item iremos apresentar como a equipe organizou-se para trabalhar no desenvolvi-
mento de cada etapa do projeto.
5.1 Estrutura da Equipe
Como dito anteriormente, a estrutura possui 5 integrantes os quais alguns trabalharam
em mais de uma área no projeto. Na Tabela 13 está descrito a contribuição de cada um.
5.2 Mecanismos de Comunicação
A comunicação foi realizada por meio de reuniões duas vezes na semana, momentos
antes da aula presencial da disciplina de gerência de projetos, auxiliada por uso de um grupo
criado com aplicativo multiplataforma de mensagens instantâneas social chamado de WhatsApp
e utilizando o aplicativo para computadores Skype para facilitar a programação em pares e
esclarecer dúvidas online.
5.3 Uso do Edu-blog como Ferramenta de Apoio
O uso do Edu-blog foi necessário em todo o desenvolvimento do projeto, pois lá
encontrava-se todo o conteúdo de gerência de projetos, necessário para o desenvolvimento
do mesmo, e diversos projetos realizados para auxiliar neste desenvolvimento.
Foi também uma excelente ferramenta de aprendizagem na experiência de interação com
grupos. Onde poderia tirar dúvidas de assuntos atuais postados por colegas de classe, ou até
mesmo, a pessoa poderia postar algo novo que aprendeu seguindo o tema passado pelo professor.

Capítulo 5. Organização do Pessoal 20
Responsável Papel Descrição
Jorge Roberto de Carvalho Junior Gerente de Projetos Responsável por conduzir toda
equipe no planejamento e controle
de execução de projetos em diversas
áreas de atuação.
Francisco L. dos Santos Analista de Riscos Responsável pela gestão de riscos
no monitoramento diário dos diver-
sos riscos no apresentados eventual-
mente no projeto
Matheus Aquino Analista de Sistemas Responsável por analisar processos,
mapeá-los com a ﬁnalidade de levan-
tar requisitos no intuito de encontrar
o melhor caminho racional (modela-
gem de dados) para que a informa-
ção possa ser processada no projeto.
Álvaro dos Santos Reis Desenvolvedor Responsável por desenvolver ou fa-
zer manutenção executando tarefas
na implementação de software do
projeto.
Silvaneide V. dos Santos Desenvolvedor e Testador Responsável por desenvolver ou fa-
zer manutenção executando tarefas
na implementação de software do
projeto. Responsável também por
implementar testes sistemáticos e
executa-los.
Tabela 13 – Tabela estrutural da equipe
Sendo assim, o blog foi utilizado para aprender coisas novas, ampliar conhecimentos
e tirar dúvidas, para que pudesse melhorar o trabalho no desenvolvimento do projeto. Ajudou
também, mobilizar alunos na busca de uma revisão, novos conhecimentos de forma virtual na
disciplina de gerência de projetos lecionada pelo professor Rogério Nascimento, em sala de aula
presencial.

21
6Precauções Tomadas para Assegurar e
Controlar a Qualidade do Produto de Soft-
ware
Nesta seção descreveremos algumas medidas previstas para que a qualidade do software
possa ser mantida diante das adversidades que possam aparecer durante a produção do software;
segundo Herman G. Weinberg “ A qualidade é relativa. O que é qualidade para uma pessoa pode
ser falta de qualidade para outra.” como medidas de controle de qualidade propomos:
• O controle de versão: O plano de versionamento do projeto tem por ﬁnalidade garantir
que eventuais alterações a serem realizadas no software sejam controladas. Sendo assim,
as versões entregues possam ser revertidas caso haja falhas no acionamento de novas
funcionalidades;
• O testes unitários: Será uma função com o objetivo de manter a corretude do código
através de testes no código do software. Tais testes devem ser feitos por uma classe com
apenas o intuito de manter a integridade do software. Tendo em vista garantir que as
funcionalidades do software se mantém diante do previsto. O código deverá ser de forma
automática a ﬁm de que eventuais esquecimento durante a confecção do software não
implique em uma quebra de qualidade do produto.

Plano de projeto: Bichos do Campus na Web

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Plano de projeto: Bichos do Campus na Web

Semelhante a Plano de projeto: Bichos do Campus na Web (20)

Último

Último (8)

Plano de projeto: Bichos do Campus na Web