SlideShare uma empresa Scribd logo
UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Plano do Projeto de Software do Sistema para Gestão de
Eventos - SIGE
Carlos Gabriel, Carlos Alberto, Euder Costa e Igor Costa
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
Carlos Gabriel, Carlos Alberto, Euder Costa e Igor Costa
Plano do Projeto de Software do Sistema para Gestão de
Eventos - SIGE
Trabalho apresentado ao Prof. Dr. Rogério Patrício
Chagas do Nascimento do curso de Sistemas de In-
formação da Universidade Federal de Sergipe, como
requisito parcial para a obtenção da nota da disciplina
Gerências de Projetos - COMP0295.
Orientador(a): Dr. Rogério Patrício Chagas do Nasci-
mento
São Cristóvão – Sergipe
2018
Lista de ilustrações
Figura 1 – Diagrama de Caso de Uso. . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Figura 2 – Classe de Domínio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Figura 3 – Diagrama de Gantt parte 1. . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figura 4 – Diagrama de Gantt parte 2. . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Lista de tabelas
Tabela 1 – Autores do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Tabela 2 – Funcionalidades do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Tabela 3 – Tabela de riscos do projeto. . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Tabela 4 – Tarefas do Projeto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Sumário
1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1 Escopo do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Funções Principais do Produto de Software . . . . . . . . . . . . . . . . . . . 7
1.3 Requisitos Comportamentais ou de Performance . . . . . . . . . . . . . . . . . 8
1.4 Gestão e Restrições Técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Estimações do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Dados Históricos utilizados para as Estimações . . . . . . . . . . . . . . . . . 10
2.2 Técnicas de Estimação e Resultados . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Técnica de Estimação . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Recursos do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1 Recursos Humanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.2 Recursos de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.3 Recursos de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Análise e Gestão de Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1 Riscos do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.1 Tamanho do Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.2 Impacto no Negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.3 Características do Envolvido . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.4 Definição do Processo . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.5 Ambiente de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . 16
3.1.6 Tecnologia a ser criada . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.7 Quantidade de pessoas e experiência . . . . . . . . . . . . . . . . . . . 16
3.2 Tabela de riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Redução e gestão do risco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Planejamento Temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1 Conjunto de Tarefas do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5 Organização do Pessoal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1 Estrutura da Equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2 Mecanismos de Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3 Uso do Edu-blog como ferramenta de apoio . . . . . . . . . . . . . . . . . . . 31
6 Preocupações Tomadas para
Assegurar e Controlar a Qualidade do Produto de Software . . . . . . . . . . . . 32
6.1 Desenvolvimento iterativo e incremental . . . . . . . . . . . . . . . . . . . . . 32
6.2 Utilização de uma metodologia Ágil para o desenvolvimento de Software . . . 32
6.3 Utilização de um guia de estilo de codificação . . . . . . . . . . . . . . . . . . 33
6.4 Uso de ferramenta para o controle de versões . . . . . . . . . . . . . . . . . . 33
6.5 Realização de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6
1Introdução
Este documento apresenta uma solução de software para a gestão de eventos e recursos
organizados no Campus da Saúde. O sistema foi demandado pela Unidade de Comunicação
Social, através da ASCOM, e será utilizado pelos setores do Hospital Universitário da UFS
(HU-UFS) para o gerenciamento de seus eventos e recursos, como também a divulgação no site
da Instituição.
1.1 Escopo do Projeto
Esse produto surge de uma problemática comum em instituições de ensino, que é ter
que controlar manualmente solicitações de eventos e/ou recursos, através de tarefas manuais
de alocação, onde ocasiona-se conflitos ou subutilização dos recursos. Normalmente, quando
alguém quer solicitar uma reserva, faz-se necessário ligar para o administrador, que por sua vez
analisa o pleito e responde.
Mas com o Sistema para Gestão de Eventos (SIGE) em funcionamento, a pessoa poderá
submeter uma solicitação de evento com recursos associados, cabendo ao sistema analisar a
demanda e efetuar as reservas, e ainda torna-se possível a interação do Administrador para
resolver quaisquer conflitos de interesses que possam ocorrer.
Dessa forma, haverá mais celeridade na solicitação e análise de eventos e reservas. O
SIGE também propiciará melhor utilização dos recursos necessários aos eventos e uma via de
divulgações de eventos, facilitando a organização dos mesmos.
Capítulo 1. Introdução 7
1.2 Funções Principais do Produto de Software
As principais funções do projeto são apresentadas na Figura 1, a qual se trata do Diagrama
de Caso de Uso.
Figura 1 – Diagrama de Caso de Uso.
Fonte: Autores.
Na Figura 1 podem ser observados os atores representados por Público Interno, Colabo-
rador e Administrador que irão utilizar as funções do produto de software a ser desenvolvido.
Cada ator representa um papel particular de usuário da aplicação. Porém, além de representar
pessoas, os atores também podem ser dispositivos de hardware ou até outras aplicações que
devam trocar informações com a aplicação a ser desenvolvida. Na Tabela 1 a seguir, descreve
brevemente cada ator da aplicação.
Ator Descrição
Colaborador Funcionários dos diversos setores.
Administrador Funcionário da ASCOM, responsável por
analisar, aprovar ou não o evento/recurso.
Público Interno Comunidade acadêmica e funcionários do
HU-UFS.
Tabela 1 – Autores do sistema
As funções principais do produto de software são listadas na Tabela 2 abaixo com a breve
descrição de cada uma.
Capítulo 1. Introdução 8
Função Descrição
Manutenir Evento Permitir ao colaborador solicitar, al-
terar e cancelar um evento.
Analisar Evento Permitir ao administrador analisar o
evento solicitado pelo colaborador,
autorizando-o ou negando-o.
Gerar lista de presença Permitir ao colaborador gerar lista
de presença das pessoas que mani-
festaram interesse em participar do
evento.
Manutenir Recursos Permitir ao administrador cadastrar,
consultar e inativar um recurso.
Reservar Recursos Permitir que na criação do evento,
sejam reservados os recursos neces-
sários.
Visualizar Evento Permitir que o público interno do
HU-UFS consulte os eventos cadas-
trados.
Manifestar interesse Permitir que o público interno do
HU-UFS solicite para ser alertado
quando um determinado evento es-
tiver próximo de acontecer, para po-
der se inscrever no evento caso seja
necessário.
Gerar relatórios Permitir a geração de relatórios dos
eventos realizados.
Tabela 2 – Funcionalidades do sistema
1.3 Requisitos Comportamentais ou de Performance
Abaixo estão descritos os requisitos não funcionais da solução Sistema para Gestão de
Eventos - SIGE separados por categorias.
• Usabilidade
– Interface intuitiva: O sistema deverá possuir interface fácil de usar pelo usuário e que
tenha uma quantidade mínima de etapas para a realização de tarefas.
• Confiabilidade
– Alta Disponibilidade: O sistema deve estar disponível 99% do tempo.
• Desempenho
– Cadastros do sistema: O sistema não deve levar mais que 5 segundos para processar
uma transação de cadastro.
Capítulo 1. Introdução 9
– Geração de relatórios: O sistema deve gerar relatórios em até 5 segundos.
• Segurança
– Controle de acesso: Todos os usuários devem possuir login e senha para acessarem o
sistema e definir quais atividades cada um desempenhará.
1.4 Gestão e Restrições Técnicas
O gerenciamento da equipe ocorre de forma remota, onde existirá apenas reuniões sema-
nais para alinhamento dos trabalhos. Dessa forma, se adapta melhor com a baixa disponibilidade
dos membros, e com a dificuldade de reunir os membros presencialmente.
O software será desenvolvido seguindo o modelo de desenvolvimento incremental, cujo
etapas produzem um sistema totalmente funcional, apesar de ainda não cobrir todos os requisitos.
E para gerenciamento de equipes será utilizado o framework Scrum pela sua flexibilidade e
adaptabilidade do gerenciamento ágil da equipe e de suas tarefas. Será utilizado também o
Planning Poker como técnica para estimar o tempo das tarefas, o Trello servirá como ferramenta
para gerenciamento de tarefas, o Slack será utilizado como canal de comunicação do projeto e o
Pomelo como metodologia de gerenciamento de tempo das tarefas.
As restrições técnicas associadas ao desenvolvimento do projeto são:
• O sistema deve utilizar apenas tecnologias Open Source (Servidor- Apache Tomcat v7;
Banco de Dados – PostgreeSQL; Linguagem de programação – Java; controle de versões -
SVN).
• A utilização do sistema será feita através de navegadores web específicos, como: Google
Chrome e Mozilla Firefox.
• O sistema deve utilizar o template AdminLTE, padrão do HU-UFS.
• O sistema deve utilizar o framework web Spring MVC, voltado para aplicações Web
orientado a objetos, que utiliza a arquitetura em camadas MVC (Model-View-Controller).
• O sistema deve ser implantado em um servidor que tenha a seguinte configuração mínima
de hardware: 4GB de RAM e processador de 2.8Mghz ou superior.
10
2Estimações do Projeto
Essa seção contém a descrição da técnica utilizada para estimar o tempo de desenvolvi-
mento do projeto SIGE.
2.1 Dados Históricos utilizados para as Estimações
Sendo esse o primeiro projeto desta equipe, não existem dados históricos a serem
utilizados para a realização de estimativas.
2.2 Técnicas de Estimação e Resultados
Para estimar o esforço e tempo necessários na conclusão do SIGE, utilizaremos a técnica
criada explicitamente para softwares Orientados a Objetos (OO) proposta por Lorenz e Kidd
(1994). Esta técnica utiliza métricas orientadas a classes que permitem gerar uma estimativa de
esforço que será gasto para o desenvolvimento do projeto. Basicamente, ela decompõe o esforço
dos requisitos em quantidade de esforço de classes por casos de uso. O método sugere ainda uma
especulação de quanto tempo será gasto para criar cada classe pertencente aqueles casos de uso.
As classes são classificadas entre classes-chave, classes de interface e classes de apoio.
As classes-chaves são as classes mais importantes para o negócio, estas classes são definidas no
diagrama de classes de domínio ou de análise. As classes de interface representam as GUIs e
comunicações entre as classes. E por fim as classes de apoio são as classes responsáveis por dar
suporte às classes-chave e demais funcionalidades de suporte ao software.
Capítulo 2. Estimações do Projeto 11
2.2.1 Técnica de Estimação
Para estimar um projeto OO com a técnica de de estimação proposta por Lorenz e Kidd
(1994) devemos seguir os seguintes passos:
1. Desenvolva estimativas usando decomposição de esforço, análise FP e qualquer outro
método para aplicações convencionais.
2. Usando o modelo de requisitos, desenvolva casos de uso e determine uma contagem.
Reconheça que o número de casos de uso pode mudar à medida que o projeto avança.
3. Com base no modelo de requisitos, determine o número de classes-chave.
4. Classifique o tipo de interface para aplicação e crie um multiplicador para as classes
de suporte onde os multiplicadores para uma interface gráfica de usuário complexa são,
respectivamente: 2,0; 2,25; 2,5; e 3,0. Multiplique o número de classes-chave (passo 3)
pelo multiplicador para obter uma estimativa do número de classes de apoio.
5. Multiplique o número total de classes (classes-chave + classes de apoio) pelo número
médio de unidades de trabalho por classe. Lorenz e Kidd (1994) sugerem 15 a 20 pessoas-
dia por classe.
6. Faça uma verificação cruzada da estimativa baseada em classes, multiplicando o número
médio de unidades de trabalho por caso de uso.
2.2.2 Resultados
Os resultados gerados pela aplicação da técnica de estimação propostas por Lorenz e
Kidd a partir do Diagrama de Classes de Domínio mostrado na Figura 2.
Os resultados gerados pela aplicação da técnica de estimação são:
• Classes chaves: 5 (Recurso, Pessoa, Reserva, Evento, Divulgação).
• Todo nosso sistema é baseado em uma interface gráfica amigável e responsiva, o que
ocasiona no aumento de trabalho e complexidade das telas.
• Desse modo utilizamos o multiplicados 3.
• Classes de suporte: 5 (classes chave) x 3 (multiplicador), obtemos o total 15 classes
suporte.
• Total de classes 5 (chaves) + 15 (suporte) = 20.
• Número médio de unidade de trabalho: 18 dias-pessoa.
Capítulo 2. Estimações do Projeto 12
Figura 2 – Classe de Domínio.
Fonte: Autores.
• Tempo previsto: 20 (classes) x 18(dias) o que resulta em 360 dias por pessoa para constru-
ção das classes.
• Como nossa equipe de desenvolvimento possui 3 pessoas concluímos que o tempo estimado
será 360 dias úteis dias/4 pessoas, resultando em 90 dias para conclusão.
2.3 Recursos do Projeto
Nesta seção são definidos os recursos humanos, recursos de software e recursos de
hardware necessários para a conclusão do projeto.
2.3.1 Recursos Humanos
A equipe deste projeto é composta por um gestor de projetos, uma analista de sistemas e
dois programadores.
Capítulo 2. Estimações do Projeto 13
2.3.2 Recursos de Software
O sistema será desenvolvido utilizando a tecnologia Web, sendo necessário as seguintes
ferramentas:
• Linguagem de Programação: Java 7;
• Sistema Gerenciador de Banco de Dados: PostgreeSQL + Hibernate;
• Servidor Web: Apache Tomcat 7.0;
• Sistema de Controle de Versão: Git;
• Tema: AdminFaces para JSF;
• Framework Web: Java JSF.
• Ferramentas case: Editor de texto (Microsoft Word e LibreOffice)
• Ferramenta de modelagem dos diagramas: StarUML.
2.3.3 Recursos de Hardware
O sistema deverá possuir as seguintes configurações de hardware para a sua correta
execução.
• O sistema deve ser implantado em um servidor que tenha a seguinte configuração mínima
de hardware: 4GB de RAM e processador de 2.8Mghz ou superior;
• Espaço no Disco Rígido 10GB ou superior.
14
3Análise e Gestão de Riscos
As incertezas fazem parte do cotidiano humano. Ainda que o conceito de risco esteja
bastante associado a perigos e impactos negativos, já vem sendo utilizado como "exposição a
consequências da incerteza". A análise de gestão de riscos estão sendo cada vez mais aplicadas
tanto no gerenciamento de perdas como no de ganhos potenciais. O risco pode ser definido como
“Evento ou condição incerta que, se ocorrer, terá um efeito positivo ou negativo sobre pelo menos
um objetivo do projeto”(PMI, 2004).
De acordo com a ISO 31000, a Gestão de Risco é a terminologia utilizada para definir
um conjunto de ações estratégicas, como identificação, administração, condução e prevenção dos
riscos ligados a uma determinada atividade. Desta forma, é possível atuar de forma preventiva,
erradicando possíveis perdas, sejam elas humanas ou materiais.
3.1 Riscos do Projeto
Riscos são eventos indesejáveis e inesperados que podem tornar indisponíveis ou degradar
a qualidade/desempenho do produto de software a ser desenvolvido. Para isto, seguimos as
subclassificações de risco de projeto proposta por Pressman (2016). Assim, foram identificados
os seguintes riscos ao desenvolvido do SIGE.
3.1.1 Tamanho do Produto
São riscos relacionados ao tamanho total do software a ser construído ou modificado.
• R01 - Falta de espaço no banco de dados: embora a cada dia o preço por memória de
armazenamento estejam cada vez mais barata, existe um risco de ter a falta de memória
para armazenamento de dados no banco de dados do sistema.
Capítulo 3. Análise e Gestão de Riscos 15
• R02 - Indisponibilidade do sistema em horário de pico: como o sistema é acessado por
diversos usuários ao mesmo tempo, pode haver uma sobrecarga de usuários acessando o
sistema em um determinado período e horário.
• R03 - Perda de dados: possibilidade de haver alguma falha no banco de dados e perder
dados importantes.
3.1.2 Impacto no Negócio
São riscos associados a restrições impostas pela gerência ou pelo mercado.
• R04 - Nível de sofisticação dos usuários finais muito baixo: os usuários podem não
possuir o conhecimento técnico necessário para utilizar o sistema, dessa forma o sistema
pode não ser utilizado.
• R05 - Custo associado as entregas atrasadas: custos que podem ou não extrapolar o
valor total previsto no planejamento, causados pelo não cumprimento de entregas dentro
do prazo.
3.1.3 Características do Envolvido
São riscos relacionados à sofisticação do cliente e a habilidade do desenvolvedor de se
comunicar com o mesmo de maneira oportuna.
• R06 - Baixa disponibilidade de tempo do cliente: O cliente é uma pessoa muito impor-
tante e cheia de compromissos na sua empresa, logo as reuniões com ele são difíceis de
serem marcadas, e quando marcadas são com tempo reduzido.
• R07 - Falha no levantamento dos requisitos: Devido ao tempo curto das reuniões a
equipe pode sofrer para entender todo o domínio do problema e as necessidades do cliente,
já que o tempo é curto, o cliente acaba deixando alguns detalhes de fora, e nem tenha uma
ideia sólida do produto que ele tem em mente.
• R08 - Participação do cliente nas revisões: o cliente não participa nas revisões do
desenvolvimento do produto.
3.1.4 Definição do Processo
São riscos associados ao grau de definição do processo de desenvolvimento e se ele é
seguido por todos na organização.
• R09 - Indisciplina em seguir frameworks e metodologias: não é fácil organizar uma
equipe com pessoas de diversos níveis de conhecimento e produtividade. Logo, seguir
Capítulo 3. Análise e Gestão de Riscos 16
uma metodologia ou framework torna-se indispensável para gerenciar todo o processo de
construção e entrega do produto.
• R10 - Falta de Visibilidade do Progresso e dos Impedimentos: a falta de uso de um
sistema que auxilie o gestor com o andamento das tarefas e seus respectivos impedimentos
pode comprometer na entrega do produto.
3.1.5 Ambiente de Desenvolvimento
São riscos associados a disponibilidade e a qualidade das ferramentas que são utilizadas
na construção do produto.
• R11 - Atualização de ferramentas: o projeto pode sofrer diversas modificações durante
o seu desenvolvimento para poder continuar a ser compatível com as ferramentas.
• R12 - Condução de revisões formais: o desenvolvedor, durante a fase de teste, pode
seguir um padrão de teste diferente do que foi definido no plano do projeto.
3.1.6 Tecnologia a ser criada
São riscos associados com a complexidade do sistema a ser construído e as "novidades"da
tecnologia que é empacotada pelo sistema.
• R13 - Tecnologia ainda “imatura”: muitas novidades tecnológicas podem apresentar pro-
blemas ainda não solucionados pelos seus criadores. Isto torna uma tecnologia “imatura”,
pois não oferecem segurança na resolução de problemas.
3.1.7 Quantidade de pessoas e experiência
São riscos associados a toda a técnica e experiência de projetos dos engenheiros de
software que farão todo o trabalho.
• R14 - Falta de capacitação técnica da equipe: a falta de capacitação técnica adequado
pode afetar diretamente no processo de desenvolvimento do projeto.
• R15 - Equipe de desenvolvimento pequena: equipe de desenvolvimento é pequena e
pode acarretar em atrasos na entrega do produto, se o escopo exigido pelo projeto for
maior do que a equipe possa dar conta.
• R16 - Atividades mal distribuídas: atividades mal distribuídas entre os membros da
equipe de desenvolvimento.
Capítulo 3. Análise e Gestão de Riscos 17
3.2 Tabela de riscos
A tabela 3 mostra os riscos identificados, sua probabilidade de ocorrência e impacto
esperado. Foi definido um ponto de corte que separa os riscos de maior probabilidade e impacto
dos outros riscos. Somente os riscos que estiverem acima do ponto de corte receberão planos de
RMMM descritos na Seção 3.3. Seguimos a ordenação dos riscos proposta por Pressman:
"Um fator de risco com alto impacto, mas uma probabilidade de ocorrência muito
baixa, não deve tomar um tempo significativo da gerência. No entanto, riscos de
alto impacto com probabilidade entre moderada e alta e riscos de baixo impacto
com alta probabilidade devem ser encaminhados para as etapas de análise de risco a
seguir"(PRESSMAN; MAXIM, 2016, p. 785).
Capítulo 3. Análise e Gestão de Riscos 18
Código Risco Probabilidade Impacto RMMMM
R04 Nível de sofisticação
dos usuários finais
muito baixo
80% Catastrófico RMMM01
R07 Falha no levantamento
dos requisitos
80% Catastrófico RMMM02
R05 Custo associado as en-
tregas atrasadas
70% Crítico RMMM03
R06 Baixa disponibilidade
de tempo do cliente
60% Catastrófico RMMM04
R02 Indisponibilidade do sis-
tema em horário de pico
60% Crítico RMMM05
R08 Participação do cliente
nas revisões
60% Crítico RMMM06
R03 Perda de dados 30% Catastrófico RMMM07
R12 Condução de revisões
formais
30% Crítico RMMM08
R09 Indisciplina em seguir
frameworks e metodolo-
gias
30% Marginal RMMM09
R10 Falta de Visibilidade do
Progresso e dos Impedi-
mentos
30% Marginal RMMM10
R13 Tecnologia ainda “ima-
tura”
30% Marginal RMMM11
R15 Equipe de desenvolvi-
mento pequena
30% Crítico RMMM12
Ponto de corte
R16 Atividades mal distribuí-
das
30% Marginal -
R14 Falta de capacitação téc-
nica da equipe
20% Crítico -
R11 Atualização de ferra-
mentas
20% Moderado -
R01 Falta de espaço no
banco de dados
5% Moderado -
Tabela 3 – Tabela de riscos do projeto.
3.3 Redução e gestão do risco
Não é possível prever tudo o que pode acontecer durante o andamento do projeto, logo
com o intuito de auxiliar a equipe no desenvolvimento de estratégias para lidar com os problemas,
as tabelas a seguir foram criadas para servir como planos de contingência caso os riscos listados
na tabela anterior aconteçam.
Capítulo 3. Análise e Gestão de Riscos 19
Risco: Nível de sofisticação dos usuários finais muito baixo
Código: RMMM01 Probabilidade: 80% Impacto: Catastrófico
Descrição: Os usuários podem não possuir o conhecimento técnico
necessário para utilizar o sistema, dessa forma o sistema pode não ser
utilizado.
Estratégia de redução: Realizar uma reunião com os usuários do siste-
mas para sanar dúvidas sobre a utilização da(s) tecnologia(s).
Plano de contingência: Promover treinamentos a fim de capacitar os
usuários do sistema.
Responsável: Igor.
Status: Em andamento.
Risco: Falha no levantamento dos requisitos pequena
Código: RMMM02 Probabilidade: 60% Impacto: Catastrófico
Descrição: Devido ao tempo curto das reuniões a equipe pode sofrer
para entender todo o domínio do problema e as necessidades do cliente,
já que o tempo é curto, o cliente acaba deixando alguns detalhes de fora,
e nem tenha uma ideia sólida do produto que ele tem em mente.
Estratégia de redução: A equipe deve aproveitar ao máximo o tempo
das reuniões com o cliente para entender o problema e extrair informa-
ções sobre a necessidade do cliente. Tirar todas as duvidas no ato, não
deixar nada acumulado para reuniões futuras.
Plano de contingência: A - Marcar reuniões específicas para revisar
com o cliente os requisitos levantados. Confirmar e pedir pela aprova-
ção dos requisitos, através de documentos legais que tornam o cliente
ciente dessas aprovações. B - Utilização de uma metodologia de desen-
volvimento ágil, onde seja mais fácil absorver mudanças, caso o cliente
não esteja satisfeito com alguma funcionalidade do sistema, ou deseje
modificar alguma funcionalidade já implementada.
Responsável: Igor.
Status: Em andamento.
Capítulo 3. Análise e Gestão de Riscos 20
Risco: Custo associado as entregas atrasadas
Código: RMMM03 Probabilidade: 70% Impacto: Crítico
Descrição: Custos que podem ou não extrapolar o valor total previsto
no planejamento, causados pelo não cumprimento de entregas dentro do
prazo.
Estratégia de redução: Escolher o time de acordo com as habilidades e
experiências anteriores individuais necessárias para a garantia do prazo
e escopo do produto.
Plano de contingência: Entrar em acordo com o cliente para que sejam
realizadas mudanças visando simplificar uma funcionalidade ou retira-la
do escopo.
Responsável: Carlos Alberto.
Status: Em andamento.
Risco: Baixa disponibilidade de tempo do cliente.
Código: RMMM04 Probabilidade: 60% Impacto: Catastrófico
Descrição: O cliente é uma pessoa muito importante e cheia de compro-
missos na sua empresa, logo as reuniões com ele são difíceis de serem
marcadas, e quando marcadas são com tempo reduzido.
Estratégia de redução: Organizar de forma mais eficiente a reunião,
para torná-la o mais objetiva e proveitosa possível. Será necessário seguir
um roteiro claro e objetivo, e deve ser evitado abordar temas que não
sejam uteis para o projeto.
Plano de contingência: Solicitar para que o cliente disponibilize al-
guém de sua confiança com conhecimento técnico e experiência na área
abordada pelo sistema. E solicitar que o cliente deixe sempre marcado
um horário na sua agenda para reunião sobre o projeto, conscientizando
ele que é essencial para o projeto. .
Responsável: Carlos Alberto e Igor.
Status: Em andamento.
Capítulo 3. Análise e Gestão de Riscos 21
Risco: Indisponibilidade do sistema em horário de pico
Código: RMMM05 Probabilidade: 60% Impacto: Crítico
Descrição: A indisponibilidade do sistema pode acarretar um impacto
profundo, tanto economicamente quanto na imagem da empresa. Pois
pode passar a impressão de que os serviços desenvolvidos são de baixa
qualidade.
Estratégia de redução: A equipe de desenvolvedores deve ficar atenta
as ferramentas de monitoramento do serviço. Para em caso de problemas
tentar restabelecer o serviço. Utilizar cópias de redundância para caso o
sistema caia, seja possível utilizar o serviço através de um backup em
outro servidor.
Plano de contingência: Utilizar formulários para dar prosseguimento ao
processo, e quando o sistema for restabelecido cadastrar esses dados no
sistema. Monitorar constantemente o sistema. Preparar backups e cópias
espelho da aplicação, para caso a imagem principal fique indisponível,
sejam usadas as cópias para subir a aplicação em um servidor de backup.
Responsável: Igor, Carlos Gabriel e Euder Costa.
Status: Em andamento.
Risco: Participação do cliente nas revisões
Código: RMMM06 Probabilidade: 60% Impacto: Moderado
Descrição: O cliente não participa nas revisões do desenvolvimento do
produto.
Estratégia de redução: Flexibilizar datas e horários das revisões, para
melhor atender as disponibilidades do cliente.
Plano de contingência: Realizar reuniões com uma pessoa de confiança
do cliente para apresentar o andamento do projeto.
Responsável: Igor.
Status: Concluída.
Capítulo 3. Análise e Gestão de Riscos 22
Risco: Perda de dados
Código: RMMM07 Probabilidade: 30% Impacto: Catastrófico
Descrição: Possibilidade de haver alguma falha no banco de dados e
perder dados importantes.
Estratégia de redução: Usar um sistema de espelhamento do banco de
dados.
Plano de contingência: Usar uma boa política de backup que deverá ser
revista anualmente para minimizar a perda e acelerar qualquer recupera-
ção necessária.
Responsável: Carlos Gabriel e Euder Costa.
Status: Em andamento.
Risco: Condução de revisões formais nos testes
Código: RMMM08 Probabilidade: 30% Impacto: Crítico
Descrição: O desenvolvedor pode seguir um padrão de testes diferente
do que foi definido no plano do projeto.
Estratégia de redução: Fazer uso de testes padrões e automatizados
para evitar que o desenvolvedor se desvirtue dos padrões determinados.
Plano de contingência: Contratar uma empresa especializada em testes
de software para auditar os testes.
Responsável: Igor, Carlos Gabriel e Euder Costa.
Status: Em análise.
Risco: Indisciplina em seguir frameworks e metodologias
Código: RMMM09 Probabilidade: 30% Impacto: Marginal
Descrição: Não é fácil organizar uma equipe com pessoas de diversos
níveis de conhecimento. Logo, seguir uma metodologia ou framework
torna-se indispensável para gerenciar todo o processo de construção e
entrega do produto.
Estratégia de redução: Realizar reuniões semanais para verificar o
andamento do projeto e suas respectivas tarefas.
Plano de contingência: Realizar reuniões visando corrigir e consci-
entizar os membros da equipe dos benefícios que trazem a utilização
dos frameworks e metodologias. E realizar treinamentos pontuais para
corrigir e guiar a equipe para reduzir ou acabar com a indisciplina.
Responsável: Igor.
Status: Em andamento.
Capítulo 3. Análise e Gestão de Riscos 23
Risco: Falta de Visibilidade do Progresso e dos Impedimentos
Código: RMMM10 Probabilidade: 30% Impacto: Marginal
Descrição: A falta de uso de um sistema que auxilia o gestor com o an-
damento das tarefas e seus respectivos impedimentos pode comprometer
na entrega do produto.
Estratégia de redução: Implementar o sistema Kanban para visualizar o
fluxo de trabalho da equipe e solicitar a participação de todos os membros
no Daily Scrum para tornar transparente o andamento e impedimentos
que estão ocorrendo na realização das suas tarefas no projeto.
Plano de contingência: Exigir que os membros se reportem diariamente
ao gerente de projetos e participem do Daily Scrum trazendo detalhes
das suas tarefas realizadas, das suas tarefas que serão executadas e dos
problemas que tem ocorrido na realização das suas tarefas.
Responsável: Igor.
Status: Andamento.
Risco: Tecnologia ainda “imatura”
Código: RMMM11 Probabilidade: 30% Impacto: Marginal
Descrição: Muitas novidades tecnológicas podem apresentar problemas
ainda não solucionados pelos seus criadores. Isto torna uma tecnologia
“imatura”, pois não oferecem segurança na resolução de problemas.
Estratégia de redução: Escolher as tecnologias que possuem as versões
estáveis no mercado e participar da comunidade dessas tecnologias,
buscando sanar duvidas e reportar problemas.
Plano de contingência: Fazer um levantamento das falhas e desenvolver
práticas/processos que possam mitigar os possíveis danos no sistema.
Participar ativamente da comunidade da tecnologia, seja para aprimorar
os conhecimentos da equipe de desenvolvimento, ou para reportar pro-
blemas e aguardar bug fixes ou soluções para contornar tais problemas.
Responsável: Igor, Carlos Alberto.
Status: Em análise.
Capítulo 3. Análise e Gestão de Riscos 24
Risco: Equipe de desenvolvimento pequena
Código: RMMM12 Probabilidade: 70% Impacto: Crítico
Descrição: Equipe de desenvolvimento é pequena e pode acarretar em
atrasos na entrega.
Estratégia de redução: Estabelecer práticas e processos ágeis que pos-
sam aumentar a produtividade e facilitar a gestão. Ajustar as tarefas para
a capacidade da equipe, e caso necessário, ainda é possível simplificar
uma funcionalidade ou até mesmo retirar-la do escopo.
Plano de contingência: Priorizar entregas mais importantes e buscar
simplificar uma funcionalidade para que seja possível agregar valor ao
produto ao final da sprint. Caso necessário é possível ajustar o escopo do
produto ao remover ou simplificar funcionalidade menos importantes.
Responsável: Igor.
Status: Em andamento.
25
4Planejamento Temporal
Nesta seção é apresentado o planejamento temporal do projeto, onde são definidas as
tarefas, as datas e a sequência de atividades que foram escolhidas para o desenvolvimento do
software.
4.1 Conjunto de Tarefas do Projeto
Incluímos no projeto as atividades do framework Scrum segundo (SCHWABER; SUTHER-
LAND, 2017).
Na Tabela 4 são apresentadas as atividades do projeto e suas respectivas tarefas a serem
executadas.
Tabela 4 – Tarefas do Projeto.
Etapa Tarefa
Planejamento e Projeto
Visão Geral do Produto de Software.
Levantamento dos Requisitos.
Criação do Diagrama de Casos de Uso.
Criação do Diagrama de Classes de Domí-
nio.
Estimação de tempo do projeto.
Realizar a Gestão de Riscos.
Preparar o ambiente de desenvolvimento.
Definir o Product Backlog.
Reunião de Sprint Planning.
Retrospectiva da Sprint
Capítulo 4. Planejamento Temporal 26
Etapa Tarefa
Desenvolvimento
Preparação do Banco de Dados.
Implementação do Caso de Uso Manutenir
Recursos.
Implementação do Caso de Uso Manutenir
Evento.
Implementação do Caso de Uso Reservar
Recursos..
Implementação do Caso de Uso Analisar
Evento.
Implementação do Caso de Uso Analisar
Visualizar Evento.
Implementação do Caso de Uso Gerar lista
de presença.
Implementação do Caso de Uso Manifes-
tar Interesse.
Implementação do Caso de Uso Gerar re-
latórios.
Implantação e testes
Execução dos Teste Unitários.
Execução dos Testes de Integração.
Revisão da Sprint.
Manual do usuário .
Documentação do projeto.
Gerar código executável.
4.2 Diagrama de Gantt
Nesta seção apresentamos as tarefas do tópico 4.1 relacionadas com o tempo, através
do Diagrama de Gantt. As tarefas foram agrupadas em três grupos de atividades metodológicas:
Planejamento, Desenvolvimento e Implantação. Como este projeto implementa os framework
Scrum, adaptamos as tarefas para suportar o uso de seus eventos e artefatos.
Utilizaremos resultado do esforço estimado no Capítulo 2. O projeto será desenvolvido
dentro de um esforço estimado de 90 dias (equivalente a 3 meses), com 100% de participação
dos recursos humanos nas tarefas. Sabendo disto, distribuímos o esforço da seguinte forma:
• Planejamento e Projeto: 40% (36 dias/pessoa).
• Desenvolvimento: 20% (18 dias/pessoa).
• Implantação e testes: 40% (36 dias/pessoa).
Capítulo 4. Planejamento Temporal 27
Desta forma, as tarefas de Planejamento e Projeto devem dividir entre si um prazo de 54
dias, de forma análoga, nas outras atividades ocorrerá o mesmo. Quanto aos detalhes do esforço
alocado para cada tarefa, veja o Diagrama de Gantt.
Capítulo 4. Planejamento Temporal 28
Figura 3 – Diagrama de Gantt parte 1.
Fonte: Autores.
Capítulo 4. Planejamento Temporal 29
Figura 4 – Diagrama de Gantt parte 2.
Fonte: Autores.
30
5Organização do Pessoal
Organizar equipes e fazer com que todos os membros trabalhem em harmonia e sintonia
é um trabalho árduo. E para facilitar o bem estar da equipe, cada um precisa estar ciente do seu
significado na equipe, das tarefas que serão exercidas e do perfil da função em questão.
5.1 Estrutura da Equipe
Responsável Cargo Descrição
Igor Gerente de Projetos Planejar, controlar e executar projetos,
sempre atento aos prazos e custos de pro-
dução.
Carlos Alberto Analista de Sistemas Analisa e desenvolve projetos de sistemas,
levanta requisitos, mapeia processos e rea-
liza modelagem de dados, com objetivo de
estudar e implementar sistemas de acordo
com as regras de negócio.
Carlos Gabriel Programador Programa, codifica e testa linguagens de
programação, com base nos sistemas de-
senvolvidos pelos analistas.
Euder Costa Testador Realizar testes durante o processo de
desenvolvimento,garantindo o funciona-
mento e a qualidade do sistema.
Capítulo 5. Organização do Pessoal 31
5.2 Mecanismos de Comunicação
Os mecanismos de comunicação utilizados serão agrupados em quatro classificações
diferentes: comunicação de projeto, comunicação de equipe, comunicação externa e comunicação
entre stakeholders.
Os aplicativos utilizados para a comunicação de projeto remetem aos padrões de comen-
tários que são feitos em linhas de código e que muitas vezes são incluídos na documentação dos
módulos. Para este, utilizaremos o padrão do JavaDoc de comentários.
Para a comunicação entre a equipe utilizaremos o Trello e o Slack, por serem ferramentas
voltadas para o desenvolvimento e são facilitadoras para reunir informações, anexos, pedaços de
código, links úteis e gerenciamento de tarefas.
Para utilização da comunicação externa utilizaremos as redes sociais como whatsapp e
facebook, como também email pessoal e corporativo e telefonia com o objetivo de facilitar a
comunicação em casos de avisos atípicos do dia a dia.
E para finalizar, utilizaremos somente o email corporativo para comunicação com os
stakeholders a fim de se ter um local seguro e confiável para manter informações sigilosas e com
isso obter a qualidade de não-repúdio sobre as comunicações.
5.3 Uso do Edu-blog como ferramenta de apoio
O uso do Edu-blog como ferramenta de apoio vem para melhorar a comunicação entre
os times de desenvolvimento e produzir novos conhecimentos e habilidades entre os envolvidos
nos projetos.
32
6Preocupações Tomadas para
Assegurar e Controlar a
Qualidade do Produto de
Software
O processo de Garantia Qualidade é formado por um conjunto planejado e sistemático de
atividades, que tem por objetivo prover confiança sobre a conformidade de produtos e serviços a
requisitos especificados e que venham ao encontro das necessidades dos usuários.
6.1 Desenvolvimento iterativo e incremental
A abordagem incremental e iterativa somente é possível se existir um mecanismo para
dividir os requisitos do sistema em partes, para que cada parte seja alocada a um ciclo de
desenvolvimento. Essa alocação é realizada em função do grau de importância atribuído a cada
requisito.
6.2 Utilização de uma metodologia Ágil para o desenvolvi-
mento de Software
Utilizaremos o Framework Scrum com todos os conceitos, valores, eventos, artefatos e
papéis nele definidos. Para tal vamos definir os seguintes eventos do Scrum:
• Sprint Planning: é a reunião de planejamento da Sprint. Ela terá a duração de 2 horas e
será feita com a presença de todo o Time Scrum.
Capítulo 6. Preocupações Tomadas para
Assegurar e Controlar a Qualidade do Produto de Software 33
• Sprints: é o período de conclusão das tarefas das sprints. As sprints terão a duração de um
mês, iniciados um dia após o Sprint Planning.
• Daily Scrum: reunião feita diariamente no mesmo horário, o objetivo é que todo o Time
Scrum conheça o que está acontecendo com os seus colegas, e assim, tomar medidas para
dirimir eventuais problemas.
• Sprint Review: reunião que é executada ao final de uma sprint para demonstrar o incre-
mento do produto aos stakeholders. Esta reunião terá a duração de 4 horas e contará com a
presença apenas do Scrum Master, do Product Owner e demais stakeholders.
• Sprint Retrospective: evento onde todos os integrantes do Time Scrum buscam identificar
pontos fortes e fracos que ocorreram durante a Sprint finalizada. Esta reunião terá a duração
de 4 horas.
6.3 Utilização de um guia de estilo de codificação
Um guia de estilo de codificação é um conjunto de requisitos obrigatórios para o leiaute
e formatação dos códigos fonte do produto de software. Com a padronização da escrita a leitura
do código se torna mais fácil, rápido entendimento da equipe com o que está sendo realizado e
aumenta a produtividade pois reduz a quantidade de escolhas não triviais que os programadores
enfrentam no seu dia a dia.
Para este projeto optamos em seguir as seguintes diretrizes:
• Usar a notação Húngara;
• Usar o método CamelCase para variáveis, nos métodos e seus parâmetros;
• Usar o TAB para indentação;
• Nome de constantes devem estar em letras maiúscula;
• Uso de comentário antes da definição do método para descrever de forma geral o seu
objetivo;
• Não escrever comentários para cada linha de código e cada variável declarada;
• Uso de pacotes (package) para separar os códigos em categorias.
6.4 Uso de ferramenta para o controle de versões
Para o versionamento do projeto escolhemos as seguintes tecnologias:
Capítulo 6. Preocupações Tomadas para
Assegurar e Controlar a Qualidade do Produto de Software 34
• Git: sistema de gerenciamento de versões distribuído, gratuíto e de código aberto. Ele foi
projetado para ser utilizado tanto em pequenos como em grandes projetos com velocidade
e eficiência.
• Bitbucket: é um sistema de gerenciamento de repositórios na nuvem. Dentre suas funcio-
nalidades, a que mais se destaca para o nosso projeto é a possibilidade de criar projetos
privados.
• Gitflow: framework de fluxo de trabalho do git. Ele ajuda a gerenciar as branches do Git,
suas releases como também os commits de forma a evitar conflitos no projeto.
6.5 Realização de testes
Segundo Pressman e Maxim (2016), aplicações OO podem utilizar os mesmos testes
de aplicados convencionais, mas é claro que adicionando a atenção às características que uma
aplicação OO possui, como por exemplo, herança e polimorfismo das classes.
Os seguintes testes serão executados neste projeto:
• Revisão de código: é uma avaliação feita por um programador, que não seja o autor
daquele códigos, onde o objetivo é ver se o código escrito segue o padrão de codificação
pré-estabelecido. Estes padrões de codificação são criados levando em consideração os
atributos de segurança, legibilidade, fácil entendimento e manutenibilidade do código.
• Teste caixa-preta: são testes de nível mais alto de abstração, não é levado em consideração
o código mas sim a execução das funcionalidades. Neste tipo de teste são avaliados se
os requisitos foram satisfeitos, se as funcionalidades estão executando corretamente, se a
interface com o usuário está corretamente implementada, exibição de dados entre outros.
• Teste caixa-branca: são testes de nível mais baixo em abstração, os detalhes do código e
suas funcionalidades mais básicas são levadas em consideração. Geralmente nesta fase são
projetados e executados os testes unitários.
• Testes de integração: são testes executados durante a fase de junção dos componentes
ou lançamento de incremento de uma release. Este teste busca encontrar falhas entre a
comunicação dos componentes e garantir o funcionamento de funcionalidades anteriores
ao incremento.
• Reuniões do Scrum: o framework Scrum trás três eventos que facilitam a comunicação e
teste de validação do projeto com os stakeholders, são elas: Sprint planning, Daily Scrum e
Sprint review. O Sprint planning é uma reunião que é feita para definir as tarefas da sprint
daquele mês, o cliente (Product Owner) define junto aos desenvolvedores (Team Scrum)
Capítulo 6. Preocupações Tomadas para
Assegurar e Controlar a Qualidade do Produto de Software 35
as tarefas necessárias para criar a release. O Daily Scrum são reuniões diárias que ajudam
a manter o gerenciamento das tarefas.
36
Referências
LORENZ, M.; KIDD, J. Object-oriented Software Metrics: A Practical Guide. PTR Prentice
Hall, 1994. (Prentice Hall object-oriented series). ISBN 9780131792920. Disponível em:
<https://books.google.com.br/books?id=lsJnQgAACAAJ>. Citado 2 vezes nas páginas 10 e 11.
PMI. A Guide To The Project Management Body Of Knowledge (PMBOK Guides). [S.l.]: Project
Management Institute, 2004. ISBN 193069945X, 9781933890517. Citado na página 14.
PRESSMAN, R.; MAXIM, B. Engenharia de Software-8ª Edição. [S.l.]: McGraw Hill Brasil,
2016. Citado 2 vezes nas páginas 17 e 34.
SCHWABER, K.; SUTHERLAND, J. The Definitive Guide to Scrum:The Rules of the
Game. 2017. Disponível em: <http://www.scrumguides.org/docs/scrumguide/v2017/
2017-Scrum-Guide-US.pdf>. Citado na página 25.

Mais conteúdo relacionado

Mais procurados

TCC Aporano Play'ed SCRUM'ces
TCC Aporano Play'ed SCRUM'cesTCC Aporano Play'ed SCRUM'ces
TCC Aporano Play'ed SCRUM'ces
Aporano Alves da Silva Torres
 
Plano de Projeto - GREENSOLAR
Plano de Projeto - GREENSOLARPlano de Projeto - GREENSOLAR
Plano de Projeto - GREENSOLAR
Robson Josué Molgaro
 
TCC Aporano Play'ed SCRUM'ces - Apresentacao
TCC Aporano Play'ed SCRUM'ces - ApresentacaoTCC Aporano Play'ed SCRUM'ces - Apresentacao
TCC Aporano Play'ed SCRUM'ces - Apresentacao
Aporano Alves da Silva Torres
 
Tcc escola educacao Gerenciamento de Projetos
Tcc escola educacao Gerenciamento de ProjetosTcc escola educacao Gerenciamento de Projetos
Tcc escola educacao Gerenciamento de Projetos
Iverson moya
 
Csi 1105 pt gestão de projectos de informática
Csi 1105 pt gestão de projectos de informáticaCsi 1105 pt gestão de projectos de informática
Csi 1105 pt gestão de projectos de informática
Crimildo Lourenco Moises
 
Pmbok3rd portuguese
Pmbok3rd portuguesePmbok3rd portuguese
Pmbok3rd portuguese
Stanlay Cruz
 
Pmbok3rd portugueseprint
Pmbok3rd portugueseprintPmbok3rd portugueseprint
Pmbok3rd portugueseprint
Claudio Martins Jr.
 
Estudo Modernização Planta Industria - Instalacao de Equipamentos Industriais...
Estudo Modernização Planta Industria - Instalacao de Equipamentos Industriais...Estudo Modernização Planta Industria - Instalacao de Equipamentos Industriais...
Estudo Modernização Planta Industria - Instalacao de Equipamentos Industriais...
Murilo Paixao
 
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
 
Guia final
Guia finalGuia final
Guia final
Rita Cabral
 
Nao conformidade2011
Nao conformidade2011Nao conformidade2011
Nao conformidade2011
Diego H. R. Gonzalez
 
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
pjclima
 
Sergio glasmeyer
Sergio glasmeyerSergio glasmeyer
Sergio glasmeyer
luiz carlos cervinski
 
Serra circular
Serra circularSerra circular
Serra circular
Raquel Duarte
 
Manual de fornecedores 3 m v8
Manual de fornecedores 3 m  v8Manual de fornecedores 3 m  v8
Manual de fornecedores 3 m v8
sayonaradenver
 
Apostila open projet 1.5
Apostila open projet 1.5Apostila open projet 1.5
Apostila open projet 1.5
Adams Franceschelli Godoy
 
Plano de projeto gp mateus schuch
Plano de projeto gp mateus schuchPlano de projeto gp mateus schuch
Plano de projeto gp mateus schuch
Mateus Schuch da Silva
 
Como programar em educaçao especial
Como programar em educaçao especialComo programar em educaçao especial
Como programar em educaçao especial
Magda Ferreira
 
Livro programaremeducaoespecial-100520070152-phpapp02
Livro programaremeducaoespecial-100520070152-phpapp02Livro programaremeducaoespecial-100520070152-phpapp02
Livro programaremeducaoespecial-100520070152-phpapp02
especialpartilha
 
Manual scada por
Manual  scada porManual  scada por
Manual scada por
Alex Buonanno
 

Mais procurados (20)

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 - GREENSOLAR
Plano de Projeto - GREENSOLARPlano de Projeto - GREENSOLAR
Plano de Projeto - GREENSOLAR
 
TCC Aporano Play'ed SCRUM'ces - Apresentacao
TCC Aporano Play'ed SCRUM'ces - ApresentacaoTCC Aporano Play'ed SCRUM'ces - Apresentacao
TCC Aporano Play'ed SCRUM'ces - Apresentacao
 
Tcc escola educacao Gerenciamento de Projetos
Tcc escola educacao Gerenciamento de ProjetosTcc escola educacao Gerenciamento de Projetos
Tcc escola educacao Gerenciamento de Projetos
 
Csi 1105 pt gestão de projectos de informática
Csi 1105 pt gestão de projectos de informáticaCsi 1105 pt gestão de projectos de informática
Csi 1105 pt gestão de projectos de informática
 
Pmbok3rd portuguese
Pmbok3rd portuguesePmbok3rd portuguese
Pmbok3rd portuguese
 
Pmbok3rd portugueseprint
Pmbok3rd portugueseprintPmbok3rd portugueseprint
Pmbok3rd portugueseprint
 
Estudo Modernização Planta Industria - Instalacao de Equipamentos Industriais...
Estudo Modernização Planta Industria - Instalacao de Equipamentos Industriais...Estudo Modernização Planta Industria - Instalacao de Equipamentos Industriais...
Estudo Modernização Planta Industria - Instalacao de Equipamentos Industriais...
 
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...
 
Guia final
Guia finalGuia final
Guia final
 
Nao conformidade2011
Nao conformidade2011Nao conformidade2011
Nao conformidade2011
 
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
 
Sergio glasmeyer
Sergio glasmeyerSergio glasmeyer
Sergio glasmeyer
 
Serra circular
Serra circularSerra circular
Serra circular
 
Manual de fornecedores 3 m v8
Manual de fornecedores 3 m  v8Manual de fornecedores 3 m  v8
Manual de fornecedores 3 m v8
 
Apostila open projet 1.5
Apostila open projet 1.5Apostila open projet 1.5
Apostila open projet 1.5
 
Plano de projeto gp mateus schuch
Plano de projeto gp mateus schuchPlano de projeto gp mateus schuch
Plano de projeto gp mateus schuch
 
Como programar em educaçao especial
Como programar em educaçao especialComo programar em educaçao especial
Como programar em educaçao especial
 
Livro programaremeducaoespecial-100520070152-phpapp02
Livro programaremeducaoespecial-100520070152-phpapp02Livro programaremeducaoespecial-100520070152-phpapp02
Livro programaremeducaoespecial-100520070152-phpapp02
 
Manual scada por
Manual  scada porManual  scada por
Manual scada por
 

Semelhante a Plano de Projeto de Software para o desenvolvimento do SIGE (Sistema de Gerenciamento de Eventos)

Plano de Projeto - Grupo Ajax
Plano de Projeto - Grupo AjaxPlano de Projeto - Grupo Ajax
Plano de Projeto - Grupo Ajax
Pre Amadeus
 
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
rafahreis
 
Audit 01-apostila-auditoria-em-si
Audit 01-apostila-auditoria-em-siAudit 01-apostila-auditoria-em-si
Audit 01-apostila-auditoria-em-si
Alves Albert
 
Monitoramento
MonitoramentoMonitoramento
Monitoramento
Tiago
 
Relatório de fim de curso
Relatório de fim de cursoRelatório de fim de curso
Relatório de fim de curso
Daniel Cláudio Angelino
 
Plano do projeto de software SIGEM - Sistema de gestão de materiais
Plano do projeto de software SIGEM - Sistema de gestão de materiaisPlano do projeto de software SIGEM - Sistema de gestão de materiais
Plano do projeto de software SIGEM - Sistema de gestão de materiais
Marcos Pessoa
 
Python gtk
Python gtkPython gtk
Python gtk
Tiago
 
Linguagem c
Linguagem cLinguagem c
Linguagem c
Tiago
 
Plano de Projeto de Software
Plano de Projeto de SoftwarePlano de Projeto de Software
Plano de Projeto de Software
Matheus Mendonça
 
Mrtg
MrtgMrtg
Mrtg
Tiago
 
Apostila cdtc dotproject
Apostila cdtc dotprojectApostila cdtc dotproject
Apostila cdtc dotproject
Tiago
 
Zope
ZopeZope
Zope
Tiago
 
Quanta
QuantaQuanta
Quanta
Tiago
 
Sql
SqlSql
Sql
Tiago
 
sistemas_operacionais-livro.pdf
sistemas_operacionais-livro.pdfsistemas_operacionais-livro.pdf
sistemas_operacionais-livro.pdf
JoelManuel8
 
Programacao cpp
Programacao cppProgramacao cpp
Programacao cpp
Tiago
 
Ec i n_boardacademic
Ec i n_boardacademicEc i n_boardacademic
Ec i n_boardacademic
Samuel Ribeiro
 
Monopoli10002160
Monopoli10002160Monopoli10002160
Monopoli10002160
Fábio Junior
 
Postgre sql
Postgre sqlPostgre sql
Postgre sql
Tiago
 
Samba
SambaSamba
Samba
Tiago
 

Semelhante a Plano de Projeto de Software para o desenvolvimento do SIGE (Sistema de Gerenciamento de Eventos) (20)

Plano de Projeto - Grupo Ajax
Plano de Projeto - Grupo AjaxPlano de Projeto - Grupo Ajax
Plano de Projeto - Grupo Ajax
 
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
 
Audit 01-apostila-auditoria-em-si
Audit 01-apostila-auditoria-em-siAudit 01-apostila-auditoria-em-si
Audit 01-apostila-auditoria-em-si
 
Monitoramento
MonitoramentoMonitoramento
Monitoramento
 
Relatório de fim de curso
Relatório de fim de cursoRelatório de fim de curso
Relatório de fim de curso
 
Plano do projeto de software SIGEM - Sistema de gestão de materiais
Plano do projeto de software SIGEM - Sistema de gestão de materiaisPlano do projeto de software SIGEM - Sistema de gestão de materiais
Plano do projeto de software SIGEM - Sistema de gestão de materiais
 
Python gtk
Python gtkPython gtk
Python gtk
 
Linguagem c
Linguagem cLinguagem c
Linguagem c
 
Plano de Projeto de Software
Plano de Projeto de SoftwarePlano de Projeto de Software
Plano de Projeto de Software
 
Mrtg
MrtgMrtg
Mrtg
 
Apostila cdtc dotproject
Apostila cdtc dotprojectApostila cdtc dotproject
Apostila cdtc dotproject
 
Zope
ZopeZope
Zope
 
Quanta
QuantaQuanta
Quanta
 
Sql
SqlSql
Sql
 
sistemas_operacionais-livro.pdf
sistemas_operacionais-livro.pdfsistemas_operacionais-livro.pdf
sistemas_operacionais-livro.pdf
 
Programacao cpp
Programacao cppProgramacao cpp
Programacao cpp
 
Ec i n_boardacademic
Ec i n_boardacademicEc i n_boardacademic
Ec i n_boardacademic
 
Monopoli10002160
Monopoli10002160Monopoli10002160
Monopoli10002160
 
Postgre sql
Postgre sqlPostgre sql
Postgre sql
 
Samba
SambaSamba
Samba
 

Plano de Projeto de Software para o desenvolvimento do SIGE (Sistema de Gerenciamento de Eventos)

  • 1. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO Plano do Projeto de Software do Sistema para Gestão de Eventos - SIGE Carlos Gabriel, Carlos Alberto, Euder Costa e Igor Costa 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 Carlos Gabriel, Carlos Alberto, Euder Costa e Igor Costa Plano do Projeto de Software do Sistema para Gestão de Eventos - SIGE Trabalho apresentado ao Prof. Dr. Rogério Patrício Chagas do Nascimento do curso de Sistemas de In- formação da Universidade Federal de Sergipe, como requisito parcial para a obtenção da nota da disciplina Gerências de Projetos - COMP0295. Orientador(a): 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 Caso de Uso. . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Figura 2 – Classe de Domínio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Figura 3 – Diagrama de Gantt parte 1. . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Figura 4 – Diagrama de Gantt parte 2. . . . . . . . . . . . . . . . . . . . . . . . . . . 29
  • 4. Lista de tabelas Tabela 1 – Autores do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Tabela 2 – Funcionalidades do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Tabela 3 – Tabela de riscos do projeto. . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Tabela 4 – Tarefas do Projeto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
  • 5. Sumário 1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1 Escopo do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2 Funções Principais do Produto de Software . . . . . . . . . . . . . . . . . . . 7 1.3 Requisitos Comportamentais ou de Performance . . . . . . . . . . . . . . . . . 8 1.4 Gestão e Restrições Técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2 Estimações do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1 Dados Históricos utilizados para as Estimações . . . . . . . . . . . . . . . . . 10 2.2 Técnicas de Estimação e Resultados . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.1 Técnica de Estimação . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3 Recursos do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.1 Recursos Humanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.2 Recursos de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.3 Recursos de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3 Análise e Gestão de Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1 Riscos do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.1 Tamanho do Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.2 Impacto no Negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.3 Características do Envolvido . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.4 Definição do Processo . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.5 Ambiente de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . 16 3.1.6 Tecnologia a ser criada . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1.7 Quantidade de pessoas e experiência . . . . . . . . . . . . . . . . . . . 16 3.2 Tabela de riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.3 Redução e gestão do risco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4 Planejamento Temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1 Conjunto de Tarefas do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2 Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5 Organização do Pessoal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.1 Estrutura da Equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.2 Mecanismos de Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.3 Uso do Edu-blog como ferramenta de apoio . . . . . . . . . . . . . . . . . . . 31
  • 6. 6 Preocupações Tomadas para Assegurar e Controlar a Qualidade do Produto de Software . . . . . . . . . . . . 32 6.1 Desenvolvimento iterativo e incremental . . . . . . . . . . . . . . . . . . . . . 32 6.2 Utilização de uma metodologia Ágil para o desenvolvimento de Software . . . 32 6.3 Utilização de um guia de estilo de codificação . . . . . . . . . . . . . . . . . . 33 6.4 Uso de ferramenta para o controle de versões . . . . . . . . . . . . . . . . . . 33 6.5 Realização de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
  • 7. 6 1Introdução Este documento apresenta uma solução de software para a gestão de eventos e recursos organizados no Campus da Saúde. O sistema foi demandado pela Unidade de Comunicação Social, através da ASCOM, e será utilizado pelos setores do Hospital Universitário da UFS (HU-UFS) para o gerenciamento de seus eventos e recursos, como também a divulgação no site da Instituição. 1.1 Escopo do Projeto Esse produto surge de uma problemática comum em instituições de ensino, que é ter que controlar manualmente solicitações de eventos e/ou recursos, através de tarefas manuais de alocação, onde ocasiona-se conflitos ou subutilização dos recursos. Normalmente, quando alguém quer solicitar uma reserva, faz-se necessário ligar para o administrador, que por sua vez analisa o pleito e responde. Mas com o Sistema para Gestão de Eventos (SIGE) em funcionamento, a pessoa poderá submeter uma solicitação de evento com recursos associados, cabendo ao sistema analisar a demanda e efetuar as reservas, e ainda torna-se possível a interação do Administrador para resolver quaisquer conflitos de interesses que possam ocorrer. Dessa forma, haverá mais celeridade na solicitação e análise de eventos e reservas. O SIGE também propiciará melhor utilização dos recursos necessários aos eventos e uma via de divulgações de eventos, facilitando a organização dos mesmos.
  • 8. Capítulo 1. Introdução 7 1.2 Funções Principais do Produto de Software As principais funções do projeto são apresentadas na Figura 1, a qual se trata do Diagrama de Caso de Uso. Figura 1 – Diagrama de Caso de Uso. Fonte: Autores. Na Figura 1 podem ser observados os atores representados por Público Interno, Colabo- rador e Administrador que irão utilizar as funções do produto de software a ser desenvolvido. Cada ator representa um papel particular de usuário da aplicação. Porém, além de representar pessoas, os atores também podem ser dispositivos de hardware ou até outras aplicações que devam trocar informações com a aplicação a ser desenvolvida. Na Tabela 1 a seguir, descreve brevemente cada ator da aplicação. Ator Descrição Colaborador Funcionários dos diversos setores. Administrador Funcionário da ASCOM, responsável por analisar, aprovar ou não o evento/recurso. Público Interno Comunidade acadêmica e funcionários do HU-UFS. Tabela 1 – Autores do sistema As funções principais do produto de software são listadas na Tabela 2 abaixo com a breve descrição de cada uma.
  • 9. Capítulo 1. Introdução 8 Função Descrição Manutenir Evento Permitir ao colaborador solicitar, al- terar e cancelar um evento. Analisar Evento Permitir ao administrador analisar o evento solicitado pelo colaborador, autorizando-o ou negando-o. Gerar lista de presença Permitir ao colaborador gerar lista de presença das pessoas que mani- festaram interesse em participar do evento. Manutenir Recursos Permitir ao administrador cadastrar, consultar e inativar um recurso. Reservar Recursos Permitir que na criação do evento, sejam reservados os recursos neces- sários. Visualizar Evento Permitir que o público interno do HU-UFS consulte os eventos cadas- trados. Manifestar interesse Permitir que o público interno do HU-UFS solicite para ser alertado quando um determinado evento es- tiver próximo de acontecer, para po- der se inscrever no evento caso seja necessário. Gerar relatórios Permitir a geração de relatórios dos eventos realizados. Tabela 2 – Funcionalidades do sistema 1.3 Requisitos Comportamentais ou de Performance Abaixo estão descritos os requisitos não funcionais da solução Sistema para Gestão de Eventos - SIGE separados por categorias. • Usabilidade – Interface intuitiva: O sistema deverá possuir interface fácil de usar pelo usuário e que tenha uma quantidade mínima de etapas para a realização de tarefas. • Confiabilidade – Alta Disponibilidade: O sistema deve estar disponível 99% do tempo. • Desempenho – Cadastros do sistema: O sistema não deve levar mais que 5 segundos para processar uma transação de cadastro.
  • 10. Capítulo 1. Introdução 9 – Geração de relatórios: O sistema deve gerar relatórios em até 5 segundos. • Segurança – Controle de acesso: Todos os usuários devem possuir login e senha para acessarem o sistema e definir quais atividades cada um desempenhará. 1.4 Gestão e Restrições Técnicas O gerenciamento da equipe ocorre de forma remota, onde existirá apenas reuniões sema- nais para alinhamento dos trabalhos. Dessa forma, se adapta melhor com a baixa disponibilidade dos membros, e com a dificuldade de reunir os membros presencialmente. O software será desenvolvido seguindo o modelo de desenvolvimento incremental, cujo etapas produzem um sistema totalmente funcional, apesar de ainda não cobrir todos os requisitos. E para gerenciamento de equipes será utilizado o framework Scrum pela sua flexibilidade e adaptabilidade do gerenciamento ágil da equipe e de suas tarefas. Será utilizado também o Planning Poker como técnica para estimar o tempo das tarefas, o Trello servirá como ferramenta para gerenciamento de tarefas, o Slack será utilizado como canal de comunicação do projeto e o Pomelo como metodologia de gerenciamento de tempo das tarefas. As restrições técnicas associadas ao desenvolvimento do projeto são: • O sistema deve utilizar apenas tecnologias Open Source (Servidor- Apache Tomcat v7; Banco de Dados – PostgreeSQL; Linguagem de programação – Java; controle de versões - SVN). • A utilização do sistema será feita através de navegadores web específicos, como: Google Chrome e Mozilla Firefox. • O sistema deve utilizar o template AdminLTE, padrão do HU-UFS. • O sistema deve utilizar o framework web Spring MVC, voltado para aplicações Web orientado a objetos, que utiliza a arquitetura em camadas MVC (Model-View-Controller). • O sistema deve ser implantado em um servidor que tenha a seguinte configuração mínima de hardware: 4GB de RAM e processador de 2.8Mghz ou superior.
  • 11. 10 2Estimações do Projeto Essa seção contém a descrição da técnica utilizada para estimar o tempo de desenvolvi- mento do projeto SIGE. 2.1 Dados Históricos utilizados para as Estimações Sendo esse o primeiro projeto desta equipe, não existem dados históricos a serem utilizados para a realização de estimativas. 2.2 Técnicas de Estimação e Resultados Para estimar o esforço e tempo necessários na conclusão do SIGE, utilizaremos a técnica criada explicitamente para softwares Orientados a Objetos (OO) proposta por Lorenz e Kidd (1994). Esta técnica utiliza métricas orientadas a classes que permitem gerar uma estimativa de esforço que será gasto para o desenvolvimento do projeto. Basicamente, ela decompõe o esforço dos requisitos em quantidade de esforço de classes por casos de uso. O método sugere ainda uma especulação de quanto tempo será gasto para criar cada classe pertencente aqueles casos de uso. As classes são classificadas entre classes-chave, classes de interface e classes de apoio. As classes-chaves são as classes mais importantes para o negócio, estas classes são definidas no diagrama de classes de domínio ou de análise. As classes de interface representam as GUIs e comunicações entre as classes. E por fim as classes de apoio são as classes responsáveis por dar suporte às classes-chave e demais funcionalidades de suporte ao software.
  • 12. Capítulo 2. Estimações do Projeto 11 2.2.1 Técnica de Estimação Para estimar um projeto OO com a técnica de de estimação proposta por Lorenz e Kidd (1994) devemos seguir os seguintes passos: 1. Desenvolva estimativas usando decomposição de esforço, análise FP e qualquer outro método para aplicações convencionais. 2. Usando o modelo de requisitos, desenvolva casos de uso e determine uma contagem. Reconheça que o número de casos de uso pode mudar à medida que o projeto avança. 3. Com base no modelo de requisitos, determine o número de classes-chave. 4. Classifique o tipo de interface para aplicação e crie um multiplicador para as classes de suporte onde os multiplicadores para uma interface gráfica de usuário complexa são, respectivamente: 2,0; 2,25; 2,5; e 3,0. Multiplique o número de classes-chave (passo 3) pelo multiplicador para obter uma estimativa do número de classes de apoio. 5. Multiplique o número total de classes (classes-chave + classes de apoio) pelo número médio de unidades de trabalho por classe. Lorenz e Kidd (1994) sugerem 15 a 20 pessoas- dia por classe. 6. Faça uma verificação cruzada da estimativa baseada em classes, multiplicando o número médio de unidades de trabalho por caso de uso. 2.2.2 Resultados Os resultados gerados pela aplicação da técnica de estimação propostas por Lorenz e Kidd a partir do Diagrama de Classes de Domínio mostrado na Figura 2. Os resultados gerados pela aplicação da técnica de estimação são: • Classes chaves: 5 (Recurso, Pessoa, Reserva, Evento, Divulgação). • Todo nosso sistema é baseado em uma interface gráfica amigável e responsiva, o que ocasiona no aumento de trabalho e complexidade das telas. • Desse modo utilizamos o multiplicados 3. • Classes de suporte: 5 (classes chave) x 3 (multiplicador), obtemos o total 15 classes suporte. • Total de classes 5 (chaves) + 15 (suporte) = 20. • Número médio de unidade de trabalho: 18 dias-pessoa.
  • 13. Capítulo 2. Estimações do Projeto 12 Figura 2 – Classe de Domínio. Fonte: Autores. • Tempo previsto: 20 (classes) x 18(dias) o que resulta em 360 dias por pessoa para constru- ção das classes. • Como nossa equipe de desenvolvimento possui 3 pessoas concluímos que o tempo estimado será 360 dias úteis dias/4 pessoas, resultando em 90 dias para conclusão. 2.3 Recursos do Projeto Nesta seção são definidos os recursos humanos, recursos de software e recursos de hardware necessários para a conclusão do projeto. 2.3.1 Recursos Humanos A equipe deste projeto é composta por um gestor de projetos, uma analista de sistemas e dois programadores.
  • 14. Capítulo 2. Estimações do Projeto 13 2.3.2 Recursos de Software O sistema será desenvolvido utilizando a tecnologia Web, sendo necessário as seguintes ferramentas: • Linguagem de Programação: Java 7; • Sistema Gerenciador de Banco de Dados: PostgreeSQL + Hibernate; • Servidor Web: Apache Tomcat 7.0; • Sistema de Controle de Versão: Git; • Tema: AdminFaces para JSF; • Framework Web: Java JSF. • Ferramentas case: Editor de texto (Microsoft Word e LibreOffice) • Ferramenta de modelagem dos diagramas: StarUML. 2.3.3 Recursos de Hardware O sistema deverá possuir as seguintes configurações de hardware para a sua correta execução. • O sistema deve ser implantado em um servidor que tenha a seguinte configuração mínima de hardware: 4GB de RAM e processador de 2.8Mghz ou superior; • Espaço no Disco Rígido 10GB ou superior.
  • 15. 14 3Análise e Gestão de Riscos As incertezas fazem parte do cotidiano humano. Ainda que o conceito de risco esteja bastante associado a perigos e impactos negativos, já vem sendo utilizado como "exposição a consequências da incerteza". A análise de gestão de riscos estão sendo cada vez mais aplicadas tanto no gerenciamento de perdas como no de ganhos potenciais. O risco pode ser definido como “Evento ou condição incerta que, se ocorrer, terá um efeito positivo ou negativo sobre pelo menos um objetivo do projeto”(PMI, 2004). De acordo com a ISO 31000, a Gestão de Risco é a terminologia utilizada para definir um conjunto de ações estratégicas, como identificação, administração, condução e prevenção dos riscos ligados a uma determinada atividade. Desta forma, é possível atuar de forma preventiva, erradicando possíveis perdas, sejam elas humanas ou materiais. 3.1 Riscos do Projeto Riscos são eventos indesejáveis e inesperados que podem tornar indisponíveis ou degradar a qualidade/desempenho do produto de software a ser desenvolvido. Para isto, seguimos as subclassificações de risco de projeto proposta por Pressman (2016). Assim, foram identificados os seguintes riscos ao desenvolvido do SIGE. 3.1.1 Tamanho do Produto São riscos relacionados ao tamanho total do software a ser construído ou modificado. • R01 - Falta de espaço no banco de dados: embora a cada dia o preço por memória de armazenamento estejam cada vez mais barata, existe um risco de ter a falta de memória para armazenamento de dados no banco de dados do sistema.
  • 16. Capítulo 3. Análise e Gestão de Riscos 15 • R02 - Indisponibilidade do sistema em horário de pico: como o sistema é acessado por diversos usuários ao mesmo tempo, pode haver uma sobrecarga de usuários acessando o sistema em um determinado período e horário. • R03 - Perda de dados: possibilidade de haver alguma falha no banco de dados e perder dados importantes. 3.1.2 Impacto no Negócio São riscos associados a restrições impostas pela gerência ou pelo mercado. • R04 - Nível de sofisticação dos usuários finais muito baixo: os usuários podem não possuir o conhecimento técnico necessário para utilizar o sistema, dessa forma o sistema pode não ser utilizado. • R05 - Custo associado as entregas atrasadas: custos que podem ou não extrapolar o valor total previsto no planejamento, causados pelo não cumprimento de entregas dentro do prazo. 3.1.3 Características do Envolvido São riscos relacionados à sofisticação do cliente e a habilidade do desenvolvedor de se comunicar com o mesmo de maneira oportuna. • R06 - Baixa disponibilidade de tempo do cliente: O cliente é uma pessoa muito impor- tante e cheia de compromissos na sua empresa, logo as reuniões com ele são difíceis de serem marcadas, e quando marcadas são com tempo reduzido. • R07 - Falha no levantamento dos requisitos: Devido ao tempo curto das reuniões a equipe pode sofrer para entender todo o domínio do problema e as necessidades do cliente, já que o tempo é curto, o cliente acaba deixando alguns detalhes de fora, e nem tenha uma ideia sólida do produto que ele tem em mente. • R08 - Participação do cliente nas revisões: o cliente não participa nas revisões do desenvolvimento do produto. 3.1.4 Definição do Processo São riscos associados ao grau de definição do processo de desenvolvimento e se ele é seguido por todos na organização. • R09 - Indisciplina em seguir frameworks e metodologias: não é fácil organizar uma equipe com pessoas de diversos níveis de conhecimento e produtividade. Logo, seguir
  • 17. Capítulo 3. Análise e Gestão de Riscos 16 uma metodologia ou framework torna-se indispensável para gerenciar todo o processo de construção e entrega do produto. • R10 - Falta de Visibilidade do Progresso e dos Impedimentos: a falta de uso de um sistema que auxilie o gestor com o andamento das tarefas e seus respectivos impedimentos pode comprometer na entrega do produto. 3.1.5 Ambiente de Desenvolvimento São riscos associados a disponibilidade e a qualidade das ferramentas que são utilizadas na construção do produto. • R11 - Atualização de ferramentas: o projeto pode sofrer diversas modificações durante o seu desenvolvimento para poder continuar a ser compatível com as ferramentas. • R12 - Condução de revisões formais: o desenvolvedor, durante a fase de teste, pode seguir um padrão de teste diferente do que foi definido no plano do projeto. 3.1.6 Tecnologia a ser criada São riscos associados com a complexidade do sistema a ser construído e as "novidades"da tecnologia que é empacotada pelo sistema. • R13 - Tecnologia ainda “imatura”: muitas novidades tecnológicas podem apresentar pro- blemas ainda não solucionados pelos seus criadores. Isto torna uma tecnologia “imatura”, pois não oferecem segurança na resolução de problemas. 3.1.7 Quantidade de pessoas e experiência São riscos associados a toda a técnica e experiência de projetos dos engenheiros de software que farão todo o trabalho. • R14 - Falta de capacitação técnica da equipe: a falta de capacitação técnica adequado pode afetar diretamente no processo de desenvolvimento do projeto. • R15 - Equipe de desenvolvimento pequena: equipe de desenvolvimento é pequena e pode acarretar em atrasos na entrega do produto, se o escopo exigido pelo projeto for maior do que a equipe possa dar conta. • R16 - Atividades mal distribuídas: atividades mal distribuídas entre os membros da equipe de desenvolvimento.
  • 18. Capítulo 3. Análise e Gestão de Riscos 17 3.2 Tabela de riscos A tabela 3 mostra os riscos identificados, sua probabilidade de ocorrência e impacto esperado. Foi definido um ponto de corte que separa os riscos de maior probabilidade e impacto dos outros riscos. Somente os riscos que estiverem acima do ponto de corte receberão planos de RMMM descritos na Seção 3.3. Seguimos a ordenação dos riscos proposta por Pressman: "Um fator de risco com alto impacto, mas uma probabilidade de ocorrência muito baixa, não deve tomar um tempo significativo da gerência. No entanto, riscos de alto impacto com probabilidade entre moderada e alta e riscos de baixo impacto com alta probabilidade devem ser encaminhados para as etapas de análise de risco a seguir"(PRESSMAN; MAXIM, 2016, p. 785).
  • 19. Capítulo 3. Análise e Gestão de Riscos 18 Código Risco Probabilidade Impacto RMMMM R04 Nível de sofisticação dos usuários finais muito baixo 80% Catastrófico RMMM01 R07 Falha no levantamento dos requisitos 80% Catastrófico RMMM02 R05 Custo associado as en- tregas atrasadas 70% Crítico RMMM03 R06 Baixa disponibilidade de tempo do cliente 60% Catastrófico RMMM04 R02 Indisponibilidade do sis- tema em horário de pico 60% Crítico RMMM05 R08 Participação do cliente nas revisões 60% Crítico RMMM06 R03 Perda de dados 30% Catastrófico RMMM07 R12 Condução de revisões formais 30% Crítico RMMM08 R09 Indisciplina em seguir frameworks e metodolo- gias 30% Marginal RMMM09 R10 Falta de Visibilidade do Progresso e dos Impedi- mentos 30% Marginal RMMM10 R13 Tecnologia ainda “ima- tura” 30% Marginal RMMM11 R15 Equipe de desenvolvi- mento pequena 30% Crítico RMMM12 Ponto de corte R16 Atividades mal distribuí- das 30% Marginal - R14 Falta de capacitação téc- nica da equipe 20% Crítico - R11 Atualização de ferra- mentas 20% Moderado - R01 Falta de espaço no banco de dados 5% Moderado - Tabela 3 – Tabela de riscos do projeto. 3.3 Redução e gestão do risco Não é possível prever tudo o que pode acontecer durante o andamento do projeto, logo com o intuito de auxiliar a equipe no desenvolvimento de estratégias para lidar com os problemas, as tabelas a seguir foram criadas para servir como planos de contingência caso os riscos listados na tabela anterior aconteçam.
  • 20. Capítulo 3. Análise e Gestão de Riscos 19 Risco: Nível de sofisticação dos usuários finais muito baixo Código: RMMM01 Probabilidade: 80% Impacto: Catastrófico Descrição: Os usuários podem não possuir o conhecimento técnico necessário para utilizar o sistema, dessa forma o sistema pode não ser utilizado. Estratégia de redução: Realizar uma reunião com os usuários do siste- mas para sanar dúvidas sobre a utilização da(s) tecnologia(s). Plano de contingência: Promover treinamentos a fim de capacitar os usuários do sistema. Responsável: Igor. Status: Em andamento. Risco: Falha no levantamento dos requisitos pequena Código: RMMM02 Probabilidade: 60% Impacto: Catastrófico Descrição: Devido ao tempo curto das reuniões a equipe pode sofrer para entender todo o domínio do problema e as necessidades do cliente, já que o tempo é curto, o cliente acaba deixando alguns detalhes de fora, e nem tenha uma ideia sólida do produto que ele tem em mente. Estratégia de redução: A equipe deve aproveitar ao máximo o tempo das reuniões com o cliente para entender o problema e extrair informa- ções sobre a necessidade do cliente. Tirar todas as duvidas no ato, não deixar nada acumulado para reuniões futuras. Plano de contingência: A - Marcar reuniões específicas para revisar com o cliente os requisitos levantados. Confirmar e pedir pela aprova- ção dos requisitos, através de documentos legais que tornam o cliente ciente dessas aprovações. B - Utilização de uma metodologia de desen- volvimento ágil, onde seja mais fácil absorver mudanças, caso o cliente não esteja satisfeito com alguma funcionalidade do sistema, ou deseje modificar alguma funcionalidade já implementada. Responsável: Igor. Status: Em andamento.
  • 21. Capítulo 3. Análise e Gestão de Riscos 20 Risco: Custo associado as entregas atrasadas Código: RMMM03 Probabilidade: 70% Impacto: Crítico Descrição: Custos que podem ou não extrapolar o valor total previsto no planejamento, causados pelo não cumprimento de entregas dentro do prazo. Estratégia de redução: Escolher o time de acordo com as habilidades e experiências anteriores individuais necessárias para a garantia do prazo e escopo do produto. Plano de contingência: Entrar em acordo com o cliente para que sejam realizadas mudanças visando simplificar uma funcionalidade ou retira-la do escopo. Responsável: Carlos Alberto. Status: Em andamento. Risco: Baixa disponibilidade de tempo do cliente. Código: RMMM04 Probabilidade: 60% Impacto: Catastrófico Descrição: O cliente é uma pessoa muito importante e cheia de compro- missos na sua empresa, logo as reuniões com ele são difíceis de serem marcadas, e quando marcadas são com tempo reduzido. Estratégia de redução: Organizar de forma mais eficiente a reunião, para torná-la o mais objetiva e proveitosa possível. Será necessário seguir um roteiro claro e objetivo, e deve ser evitado abordar temas que não sejam uteis para o projeto. Plano de contingência: Solicitar para que o cliente disponibilize al- guém de sua confiança com conhecimento técnico e experiência na área abordada pelo sistema. E solicitar que o cliente deixe sempre marcado um horário na sua agenda para reunião sobre o projeto, conscientizando ele que é essencial para o projeto. . Responsável: Carlos Alberto e Igor. Status: Em andamento.
  • 22. Capítulo 3. Análise e Gestão de Riscos 21 Risco: Indisponibilidade do sistema em horário de pico Código: RMMM05 Probabilidade: 60% Impacto: Crítico Descrição: A indisponibilidade do sistema pode acarretar um impacto profundo, tanto economicamente quanto na imagem da empresa. Pois pode passar a impressão de que os serviços desenvolvidos são de baixa qualidade. Estratégia de redução: A equipe de desenvolvedores deve ficar atenta as ferramentas de monitoramento do serviço. Para em caso de problemas tentar restabelecer o serviço. Utilizar cópias de redundância para caso o sistema caia, seja possível utilizar o serviço através de um backup em outro servidor. Plano de contingência: Utilizar formulários para dar prosseguimento ao processo, e quando o sistema for restabelecido cadastrar esses dados no sistema. Monitorar constantemente o sistema. Preparar backups e cópias espelho da aplicação, para caso a imagem principal fique indisponível, sejam usadas as cópias para subir a aplicação em um servidor de backup. Responsável: Igor, Carlos Gabriel e Euder Costa. Status: Em andamento. Risco: Participação do cliente nas revisões Código: RMMM06 Probabilidade: 60% Impacto: Moderado Descrição: O cliente não participa nas revisões do desenvolvimento do produto. Estratégia de redução: Flexibilizar datas e horários das revisões, para melhor atender as disponibilidades do cliente. Plano de contingência: Realizar reuniões com uma pessoa de confiança do cliente para apresentar o andamento do projeto. Responsável: Igor. Status: Concluída.
  • 23. Capítulo 3. Análise e Gestão de Riscos 22 Risco: Perda de dados Código: RMMM07 Probabilidade: 30% Impacto: Catastrófico Descrição: Possibilidade de haver alguma falha no banco de dados e perder dados importantes. Estratégia de redução: Usar um sistema de espelhamento do banco de dados. Plano de contingência: Usar uma boa política de backup que deverá ser revista anualmente para minimizar a perda e acelerar qualquer recupera- ção necessária. Responsável: Carlos Gabriel e Euder Costa. Status: Em andamento. Risco: Condução de revisões formais nos testes Código: RMMM08 Probabilidade: 30% Impacto: Crítico Descrição: O desenvolvedor pode seguir um padrão de testes diferente do que foi definido no plano do projeto. Estratégia de redução: Fazer uso de testes padrões e automatizados para evitar que o desenvolvedor se desvirtue dos padrões determinados. Plano de contingência: Contratar uma empresa especializada em testes de software para auditar os testes. Responsável: Igor, Carlos Gabriel e Euder Costa. Status: Em análise. Risco: Indisciplina em seguir frameworks e metodologias Código: RMMM09 Probabilidade: 30% Impacto: Marginal Descrição: Não é fácil organizar uma equipe com pessoas de diversos níveis de conhecimento. Logo, seguir uma metodologia ou framework torna-se indispensável para gerenciar todo o processo de construção e entrega do produto. Estratégia de redução: Realizar reuniões semanais para verificar o andamento do projeto e suas respectivas tarefas. Plano de contingência: Realizar reuniões visando corrigir e consci- entizar os membros da equipe dos benefícios que trazem a utilização dos frameworks e metodologias. E realizar treinamentos pontuais para corrigir e guiar a equipe para reduzir ou acabar com a indisciplina. Responsável: Igor. Status: Em andamento.
  • 24. Capítulo 3. Análise e Gestão de Riscos 23 Risco: Falta de Visibilidade do Progresso e dos Impedimentos Código: RMMM10 Probabilidade: 30% Impacto: Marginal Descrição: A falta de uso de um sistema que auxilia o gestor com o an- damento das tarefas e seus respectivos impedimentos pode comprometer na entrega do produto. Estratégia de redução: Implementar o sistema Kanban para visualizar o fluxo de trabalho da equipe e solicitar a participação de todos os membros no Daily Scrum para tornar transparente o andamento e impedimentos que estão ocorrendo na realização das suas tarefas no projeto. Plano de contingência: Exigir que os membros se reportem diariamente ao gerente de projetos e participem do Daily Scrum trazendo detalhes das suas tarefas realizadas, das suas tarefas que serão executadas e dos problemas que tem ocorrido na realização das suas tarefas. Responsável: Igor. Status: Andamento. Risco: Tecnologia ainda “imatura” Código: RMMM11 Probabilidade: 30% Impacto: Marginal Descrição: Muitas novidades tecnológicas podem apresentar problemas ainda não solucionados pelos seus criadores. Isto torna uma tecnologia “imatura”, pois não oferecem segurança na resolução de problemas. Estratégia de redução: Escolher as tecnologias que possuem as versões estáveis no mercado e participar da comunidade dessas tecnologias, buscando sanar duvidas e reportar problemas. Plano de contingência: Fazer um levantamento das falhas e desenvolver práticas/processos que possam mitigar os possíveis danos no sistema. Participar ativamente da comunidade da tecnologia, seja para aprimorar os conhecimentos da equipe de desenvolvimento, ou para reportar pro- blemas e aguardar bug fixes ou soluções para contornar tais problemas. Responsável: Igor, Carlos Alberto. Status: Em análise.
  • 25. Capítulo 3. Análise e Gestão de Riscos 24 Risco: Equipe de desenvolvimento pequena Código: RMMM12 Probabilidade: 70% Impacto: Crítico Descrição: Equipe de desenvolvimento é pequena e pode acarretar em atrasos na entrega. Estratégia de redução: Estabelecer práticas e processos ágeis que pos- sam aumentar a produtividade e facilitar a gestão. Ajustar as tarefas para a capacidade da equipe, e caso necessário, ainda é possível simplificar uma funcionalidade ou até mesmo retirar-la do escopo. Plano de contingência: Priorizar entregas mais importantes e buscar simplificar uma funcionalidade para que seja possível agregar valor ao produto ao final da sprint. Caso necessário é possível ajustar o escopo do produto ao remover ou simplificar funcionalidade menos importantes. Responsável: Igor. Status: Em andamento.
  • 26. 25 4Planejamento Temporal Nesta seção é apresentado o planejamento temporal do projeto, onde são definidas as tarefas, as datas e a sequência de atividades que foram escolhidas para o desenvolvimento do software. 4.1 Conjunto de Tarefas do Projeto Incluímos no projeto as atividades do framework Scrum segundo (SCHWABER; SUTHER- LAND, 2017). Na Tabela 4 são apresentadas as atividades do projeto e suas respectivas tarefas a serem executadas. Tabela 4 – Tarefas do Projeto. Etapa Tarefa Planejamento e Projeto Visão Geral do Produto de Software. Levantamento dos Requisitos. Criação do Diagrama de Casos de Uso. Criação do Diagrama de Classes de Domí- nio. Estimação de tempo do projeto. Realizar a Gestão de Riscos. Preparar o ambiente de desenvolvimento. Definir o Product Backlog. Reunião de Sprint Planning. Retrospectiva da Sprint
  • 27. Capítulo 4. Planejamento Temporal 26 Etapa Tarefa Desenvolvimento Preparação do Banco de Dados. Implementação do Caso de Uso Manutenir Recursos. Implementação do Caso de Uso Manutenir Evento. Implementação do Caso de Uso Reservar Recursos.. Implementação do Caso de Uso Analisar Evento. Implementação do Caso de Uso Analisar Visualizar Evento. Implementação do Caso de Uso Gerar lista de presença. Implementação do Caso de Uso Manifes- tar Interesse. Implementação do Caso de Uso Gerar re- latórios. Implantação e testes Execução dos Teste Unitários. Execução dos Testes de Integração. Revisão da Sprint. Manual do usuário . Documentação do projeto. Gerar código executável. 4.2 Diagrama de Gantt Nesta seção apresentamos as tarefas do tópico 4.1 relacionadas com o tempo, através do Diagrama de Gantt. As tarefas foram agrupadas em três grupos de atividades metodológicas: Planejamento, Desenvolvimento e Implantação. Como este projeto implementa os framework Scrum, adaptamos as tarefas para suportar o uso de seus eventos e artefatos. Utilizaremos resultado do esforço estimado no Capítulo 2. O projeto será desenvolvido dentro de um esforço estimado de 90 dias (equivalente a 3 meses), com 100% de participação dos recursos humanos nas tarefas. Sabendo disto, distribuímos o esforço da seguinte forma: • Planejamento e Projeto: 40% (36 dias/pessoa). • Desenvolvimento: 20% (18 dias/pessoa). • Implantação e testes: 40% (36 dias/pessoa).
  • 28. Capítulo 4. Planejamento Temporal 27 Desta forma, as tarefas de Planejamento e Projeto devem dividir entre si um prazo de 54 dias, de forma análoga, nas outras atividades ocorrerá o mesmo. Quanto aos detalhes do esforço alocado para cada tarefa, veja o Diagrama de Gantt.
  • 29. Capítulo 4. Planejamento Temporal 28 Figura 3 – Diagrama de Gantt parte 1. Fonte: Autores.
  • 30. Capítulo 4. Planejamento Temporal 29 Figura 4 – Diagrama de Gantt parte 2. Fonte: Autores.
  • 31. 30 5Organização do Pessoal Organizar equipes e fazer com que todos os membros trabalhem em harmonia e sintonia é um trabalho árduo. E para facilitar o bem estar da equipe, cada um precisa estar ciente do seu significado na equipe, das tarefas que serão exercidas e do perfil da função em questão. 5.1 Estrutura da Equipe Responsável Cargo Descrição Igor Gerente de Projetos Planejar, controlar e executar projetos, sempre atento aos prazos e custos de pro- dução. Carlos Alberto Analista de Sistemas Analisa e desenvolve projetos de sistemas, levanta requisitos, mapeia processos e rea- liza modelagem de dados, com objetivo de estudar e implementar sistemas de acordo com as regras de negócio. Carlos Gabriel Programador Programa, codifica e testa linguagens de programação, com base nos sistemas de- senvolvidos pelos analistas. Euder Costa Testador Realizar testes durante o processo de desenvolvimento,garantindo o funciona- mento e a qualidade do sistema.
  • 32. Capítulo 5. Organização do Pessoal 31 5.2 Mecanismos de Comunicação Os mecanismos de comunicação utilizados serão agrupados em quatro classificações diferentes: comunicação de projeto, comunicação de equipe, comunicação externa e comunicação entre stakeholders. Os aplicativos utilizados para a comunicação de projeto remetem aos padrões de comen- tários que são feitos em linhas de código e que muitas vezes são incluídos na documentação dos módulos. Para este, utilizaremos o padrão do JavaDoc de comentários. Para a comunicação entre a equipe utilizaremos o Trello e o Slack, por serem ferramentas voltadas para o desenvolvimento e são facilitadoras para reunir informações, anexos, pedaços de código, links úteis e gerenciamento de tarefas. Para utilização da comunicação externa utilizaremos as redes sociais como whatsapp e facebook, como também email pessoal e corporativo e telefonia com o objetivo de facilitar a comunicação em casos de avisos atípicos do dia a dia. E para finalizar, utilizaremos somente o email corporativo para comunicação com os stakeholders a fim de se ter um local seguro e confiável para manter informações sigilosas e com isso obter a qualidade de não-repúdio sobre as comunicações. 5.3 Uso do Edu-blog como ferramenta de apoio O uso do Edu-blog como ferramenta de apoio vem para melhorar a comunicação entre os times de desenvolvimento e produzir novos conhecimentos e habilidades entre os envolvidos nos projetos.
  • 33. 32 6Preocupações Tomadas para Assegurar e Controlar a Qualidade do Produto de Software O processo de Garantia Qualidade é formado por um conjunto planejado e sistemático de atividades, que tem por objetivo prover confiança sobre a conformidade de produtos e serviços a requisitos especificados e que venham ao encontro das necessidades dos usuários. 6.1 Desenvolvimento iterativo e incremental A abordagem incremental e iterativa somente é possível se existir um mecanismo para dividir os requisitos do sistema em partes, para que cada parte seja alocada a um ciclo de desenvolvimento. Essa alocação é realizada em função do grau de importância atribuído a cada requisito. 6.2 Utilização de uma metodologia Ágil para o desenvolvi- mento de Software Utilizaremos o Framework Scrum com todos os conceitos, valores, eventos, artefatos e papéis nele definidos. Para tal vamos definir os seguintes eventos do Scrum: • Sprint Planning: é a reunião de planejamento da Sprint. Ela terá a duração de 2 horas e será feita com a presença de todo o Time Scrum.
  • 34. Capítulo 6. Preocupações Tomadas para Assegurar e Controlar a Qualidade do Produto de Software 33 • Sprints: é o período de conclusão das tarefas das sprints. As sprints terão a duração de um mês, iniciados um dia após o Sprint Planning. • Daily Scrum: reunião feita diariamente no mesmo horário, o objetivo é que todo o Time Scrum conheça o que está acontecendo com os seus colegas, e assim, tomar medidas para dirimir eventuais problemas. • Sprint Review: reunião que é executada ao final de uma sprint para demonstrar o incre- mento do produto aos stakeholders. Esta reunião terá a duração de 4 horas e contará com a presença apenas do Scrum Master, do Product Owner e demais stakeholders. • Sprint Retrospective: evento onde todos os integrantes do Time Scrum buscam identificar pontos fortes e fracos que ocorreram durante a Sprint finalizada. Esta reunião terá a duração de 4 horas. 6.3 Utilização de um guia de estilo de codificação Um guia de estilo de codificação é um conjunto de requisitos obrigatórios para o leiaute e formatação dos códigos fonte do produto de software. Com a padronização da escrita a leitura do código se torna mais fácil, rápido entendimento da equipe com o que está sendo realizado e aumenta a produtividade pois reduz a quantidade de escolhas não triviais que os programadores enfrentam no seu dia a dia. Para este projeto optamos em seguir as seguintes diretrizes: • Usar a notação Húngara; • Usar o método CamelCase para variáveis, nos métodos e seus parâmetros; • Usar o TAB para indentação; • Nome de constantes devem estar em letras maiúscula; • Uso de comentário antes da definição do método para descrever de forma geral o seu objetivo; • Não escrever comentários para cada linha de código e cada variável declarada; • Uso de pacotes (package) para separar os códigos em categorias. 6.4 Uso de ferramenta para o controle de versões Para o versionamento do projeto escolhemos as seguintes tecnologias:
  • 35. Capítulo 6. Preocupações Tomadas para Assegurar e Controlar a Qualidade do Produto de Software 34 • Git: sistema de gerenciamento de versões distribuído, gratuíto e de código aberto. Ele foi projetado para ser utilizado tanto em pequenos como em grandes projetos com velocidade e eficiência. • Bitbucket: é um sistema de gerenciamento de repositórios na nuvem. Dentre suas funcio- nalidades, a que mais se destaca para o nosso projeto é a possibilidade de criar projetos privados. • Gitflow: framework de fluxo de trabalho do git. Ele ajuda a gerenciar as branches do Git, suas releases como também os commits de forma a evitar conflitos no projeto. 6.5 Realização de testes Segundo Pressman e Maxim (2016), aplicações OO podem utilizar os mesmos testes de aplicados convencionais, mas é claro que adicionando a atenção às características que uma aplicação OO possui, como por exemplo, herança e polimorfismo das classes. Os seguintes testes serão executados neste projeto: • Revisão de código: é uma avaliação feita por um programador, que não seja o autor daquele códigos, onde o objetivo é ver se o código escrito segue o padrão de codificação pré-estabelecido. Estes padrões de codificação são criados levando em consideração os atributos de segurança, legibilidade, fácil entendimento e manutenibilidade do código. • Teste caixa-preta: são testes de nível mais alto de abstração, não é levado em consideração o código mas sim a execução das funcionalidades. Neste tipo de teste são avaliados se os requisitos foram satisfeitos, se as funcionalidades estão executando corretamente, se a interface com o usuário está corretamente implementada, exibição de dados entre outros. • Teste caixa-branca: são testes de nível mais baixo em abstração, os detalhes do código e suas funcionalidades mais básicas são levadas em consideração. Geralmente nesta fase são projetados e executados os testes unitários. • Testes de integração: são testes executados durante a fase de junção dos componentes ou lançamento de incremento de uma release. Este teste busca encontrar falhas entre a comunicação dos componentes e garantir o funcionamento de funcionalidades anteriores ao incremento. • Reuniões do Scrum: o framework Scrum trás três eventos que facilitam a comunicação e teste de validação do projeto com os stakeholders, são elas: Sprint planning, Daily Scrum e Sprint review. O Sprint planning é uma reunião que é feita para definir as tarefas da sprint daquele mês, o cliente (Product Owner) define junto aos desenvolvedores (Team Scrum)
  • 36. Capítulo 6. Preocupações Tomadas para Assegurar e Controlar a Qualidade do Produto de Software 35 as tarefas necessárias para criar a release. O Daily Scrum são reuniões diárias que ajudam a manter o gerenciamento das tarefas.
  • 37. 36 Referências LORENZ, M.; KIDD, J. Object-oriented Software Metrics: A Practical Guide. PTR Prentice Hall, 1994. (Prentice Hall object-oriented series). ISBN 9780131792920. Disponível em: <https://books.google.com.br/books?id=lsJnQgAACAAJ>. Citado 2 vezes nas páginas 10 e 11. PMI. A Guide To The Project Management Body Of Knowledge (PMBOK Guides). [S.l.]: Project Management Institute, 2004. ISBN 193069945X, 9781933890517. Citado na página 14. PRESSMAN, R.; MAXIM, B. Engenharia de Software-8ª Edição. [S.l.]: McGraw Hill Brasil, 2016. Citado 2 vezes nas páginas 17 e 34. SCHWABER, K.; SUTHERLAND, J. The Definitive Guide to Scrum:The Rules of the Game. 2017. Disponível em: <http://www.scrumguides.org/docs/scrumguide/v2017/ 2017-Scrum-Guide-US.pdf>. Citado na página 25.