1. CIENCIAS-HUMANAS-GLOBALIZAÇÃO, TEMPO E ESPAÇO-V1.pdf
plano_de_projeto_controlart_rascunho
1. UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
CURSO DE SISTEMAS DE INFORMAÇÃO - BACHARELADO
GERÊNCIA DE PROJETOS 2013/2
Gustavo Souza Santos
Kevin Filipe Campos Matias
Onezino Gabriel Moreira
Tiago Oliveira Santos
PLANO DE PROJETO DE SOFTWARE PARA PRODUTOS DA
LACERTAE SW
São Cristóvão - Sergipe, Brasil
2014
2. UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
CURSO DE SISTEMAS DE INFORMAÇÃO - BACHARELADO
GERÊNCIA DE PROJETOS 2013/2
Gustavo Souza Santos
Kevin Filipe Campos Matias
Onezino Gabriel Moreira
Tiago Oliveira Santos
PLANO DE PROJETO DE SOFTWARE PARA PRODUTOS DA
LACERTAE SW
Trabalho apresentado ao Prof. Dr.
Rogério
Patrício
Chagas
do
Nascimento como nota parcial para
disciplina Gerência de Projetos do
curso de graduação em Sistemas de
Informação
–
Bacharelado
Universidade Federal de Sergipe.
São Cristóvão - Sergipe, Brasil
2014
da
3. Sumário
1. INTRODUÇÃO ................................................................................................. 4
1.1 Âmbito do projeto ........................................................................................ 4
1.2 Principais funções do produto de software ................................................. 5
1.3 Requisitos comportamentais ou de performance ........................................ 6
1.4 Gestão e restrições técnicas ....................................................................... 6
2. ESTIMATIVAS DO PROJETO.......................................................................... 6
2.1 Dados históricos utilizados para as estimações .......................................... 6
2.2 Técnicas de estimação e resultados ........................................................... 7
2.2.1 Técnica de estimação........................................................................... 8
2.3 Resultados .................................................................................................. 8
2.4 Recursos do projeto .................................................................................... 9
2.4.1 Recursos humanos............................................................................... 9
2.4.2 Recursos de software ......................................................................... 11
2.4.3 Recursos de hardware ....................................................................... 11
3 ANÁLISE E GESTÃO DE RISCOS ................................................................. 12
3.1 Riscos do projeto ...................................................................................... 12
3.2 Tabela de riscos ........................................................................................ 13
3.3 Redução e gestão do risco ....................................................................... 14
4 Planejamento Temporal .................................................................................. 19
4.1 Conjunto de Tarefas do Projeto ................................................................ 19
4.2 Diagrama de Gantt .................................................................................... 20
5.0 ORGANIZAÇÃO DO PESSOAL ................................................................... 21
5.1 Estrutura da equipe ................................................................................... 21
5.2 Mecanismos de comunicação ................................................................... 21
5.3 Uso do Edu-blog como ferramenta de apoio............................................. 21
6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A
QUALIDADE DO PRODUTO DE SOFTWARE ............................................................. 21
4. 1. INTRODUÇÃO
1.1 Âmbito do projeto
Um estudo realizado por alunos do curso de Sistemas de Informação da
Universidade Federal de Sergipe comprovou que não existem softwares nacionais
capazes de gerenciar um acervo de arte por completo e que a única forma de alcançar
tal objetivo, utilizando métodos atuais, seria através de ferramentas de propósitos
distintos que auxiliariam no processo de armazenamento e manipulação de
informações referentes ao acervo. Esse modo de proceder, obviamente, está sujeito a
uma infinidade de erros que podem prejudicar a qualidade, a disponibilidade e a
segurança do serviço prestado tanto ao fornecedor quanto aos seus clientes.
O sistema para Controle de Acervo de Arte (ControlArt) apresenta uma solução
definitiva para esta problemática. É por esse motivo, construir um ambiente único para
o gerenciamento de acervos, que o seu domínio é bastante extenso. A seguir serão
listados artefatos que descrevem de forma sucinta o contexto do problema e a solução
proposta:
Figura 1 - Descrição do problema
5. Figura 2 - Situação de posição do produto
1.2 Principais funções do produto de software
O diagrama abaixo apresenta as principais funcionalidades do sistema
ControlArt. Os casos de uso que envolvem manutenibilidade de determinado objeto
estão relacionados com as seguintes operações: Incluir, alterar e inativar. Os demais
itens tratam apenas de inclusão.
Figura 3 - Diagrama de casos de uso
6. 1.3 Requisitos comportamentais ou de performance
Para atender seus usuários com eficiência e qualidade, o sistema ControlArt
deve:
1. Estar de acordo com a regra de negócio do ambiente para o qual foi
desenvolvido, o que resulta na similaridades de operações para os
usuários;
2. Ser fácil de usar, a fim de proporcionar agilidade e precisão na realização
dessas operações;
3. Disponibilizar informações íntegras a todo instante;
4. Restringir o acesso de pessoas não autorizadas, utilizando um processo
de autenticação por login, senha e tipo do usuário logado (administrador
ou usuário padrão);
5. Não permitir que os usuários excluam as informações armazenadas,
apenas inativando-as quando não forem mais necessárias;
6. Não permitir que os usuários editem transações.
1.4 Gestão e restrições técnicas
Abaixo serão listadas algumas restrições técnicas do sistema ControlArt:
1. O sistema deve ser desenvolvido utilizando arquitetura web;
2. O sistema deve ser desenvolvido utilizando a linguagem de programação
Java;
3. O sistema deve utilizar o PostgreSQL como banco de dados;
4. O acesso ao sistema deve ser feito através de um browser (navegador
web). Recomenda-se fortemente o uso do Google Chrome.
2. ESTIMATIVAS DO PROJETO
Nesta seção serão descritas as estimativas que permitem calcular custo, esforço
e tempo gastos durante a construção do projeto. Essas informações são úteis para
analisar e distribuir as atividades de acordo com um cronograma preciso de tempo e
recursos necessários para cada uma delas.
2.1 Dados históricos utilizados para as estimações
Por se tratar de um projeto didático novo, sob a responsabilidade de uma equipe
recém formada, não existem dados históricos utilizados para as estimações.
7. 2.2 Técnicas de estimação e resultados
Abaixo serão listadas as técnicas utilizadas para as estimativas:
1. Métrica de Lorens & Kidd - Calcular o tempo total de duração do projeto. Utiliza o
diagrama de classes de domínio como fonte de informações.
Figura 4 - Diagrama de classes de domínio
8. 2.2.1 Técnica de estimação
A métrica mencionada no item 1 da seção anterior foi utilizada de acordo com os
seguintes passos:
1. Determinar as classes-chave do projeto, através da análise do diagrama de
classes de domínio (apresentado na Figura 4);
2. Determinar o tipo da interface do projeto, que deve ser classificada de acordo
com um dos itens da Tabela 1;
Interface
Multiplicador
Interface não gráfica
2
Baseada em texto
2,25
GUI
2,5
GUI Complexa
3
Tabela 1 - Valores Interface x Multiplicador
3. Determinar o número de classes de suporte, efetuando o produto da quantidade
de classes-chave pelo multiplicador da interface escolhida anteriormente;
4. Determinar o total de classes do projeto, somando a quantidade de classes de
suporte com a quantidade de classes-chave;
5. Determinar a quantidade de dias que uma pessoa levaria para construir uma
classe. Quando não existem dados históricos a serem considerados, Lorens &
Kidd sugerem de 15 a 20 dias;
6. Determinar a quantidade total de dias que uma pessoa levaria para construir
todo o projeto, efetuando o produto do total de classes do projeto pela
quantidade de dias escolhida anteriormente;
7. Determinar a quantidade total de dias que a equipe levaria para construir todo o
projeto, efetuando a divisão da quantidade total de dias pela quantidade de
pessoas que a equipe possui.
2.3 Resultados
Abaixo será listado o passo-a-passo da execução da métrica descrita na seção
anterior:
1. Número de classes-chave encontradas após a análise do diagrama de classes
9. de domínio;
8 classes-chave
2. Interface selecionada (De acordo com o modelo de arquitetura do sistema);
GUI
3. Número de classes de suporte encontrado;
8 (item 1) x 2,5 (multiplicador do item 2) = 20 classes de suporte
4. Número total de classes;
20 (item 1) + 8 (item 3) = 28 classes
5. Quantidade de dias que uma pessoa gastaria para desenvolver uma única
classe (Valor retirado do intervalo sugerido por Lorens & Kidd);
15 dias
6. Quantidade total de dias que uma pessoa gastaria para construir todo o sistema;
15 (item 5) * 28 (item 4) = 420 dias
7. Quantidade total de dias que a equipe gastaria para construir todo o sistema.
420 (item 6) / 4 (quantidade de integrantes) = 105 dias.
Sendo assim, de acordo com a métrica de Lorens & Kidd, o tempo necessário
para a construção do projeto deve ser de, aproximadamente, 105 dias. Levando em
consideração a quantidade de dias úteis no mês (geralmente 22), o projeto se
estenderá por, aproximadamente, 5 meses.
2.4 Recursos do projeto
Nas seções abaixo serão listados os recursos utilizados na construção do
projeto, divididos de acordo com a seguinte classificação: humanos, de software e de
hardware.
2.4.1 Recursos humanos
Para facilitar o trabalho realizado pela equipe, a duração total do projeto,
calculada na seção 2.3, foi dividida de acordo com as seguintes fases:
10. Fase
Porcentagem
Duração
Planejamento
10%
10 dias
Análise e Projeto
42%
45 dias
Codificação
28%
30 dias
Testes
20%
20 dias
Tabela 2 - Fases do projeto
Para gerenciar o projeto de software utilizamos a metodologia SCRUM. As
funcionalidades após serem definidas foram especificadas e divididas em tarefas,
essas tarefas, agrupadas e divididas entre os sprints. Ao final de cada sprint
entregaremos para os usuários uma parte funcional do software. A cada sprint fazemos
o planejamento, codificação e teste do projeto de software.
A cada sprint faremos o rodizio de funcionários nas posições de Scrum Master e
desenvolvedores, os testes serão feito pelos desenvolvedores. Cada desenvolvedor
será responsável pelos testes das implementações das atividade de outro
desenvolvedor. A tabela 3 mostra a divisão das funcionalidades dos sprints e a
indicação do Scrum Master do sprint.
Funcionalidades
Início
Término
Scrum Master
Manter tipos de pessoas;
Manter pessoas;
Manter usuários.
05/05/2014
30/05/2014
Onezino Moreira
Manter classificação;
Manter acervos.
02/06/2014
20/06/2014
Gustavo Souza
Manter peças;
Registrar transação.
23/06/2014
11/07/2014
Kevin Filipe
Tabela 3 - Definição dos Sprints
11. 2.4.2 Recursos de software
Segue abaixo a lista de recursos de software utilizados no projeto:
Software
Descrição
Java Development Kit 7
Ambiente para desenvolvimento de
aplicações Java (linguagem utilizada
na codificação do projeto).
Apache Tomcat 7
Contâiner
web
utilizado
para
armazenar e distribuir o software
desenvolvido.
PostgreSQL 9
Banco de
software.
iReport 4
Ferramenta gráfica utilizada para a
criação de relatórios personalizados.
GIT
Sistema para controle de versão
utilizado no projeto.
IDE Eclise Kepler para Java EE
IDE utilizada
software.
Google Chrome
Navegador
web
utilizado
desenvolver o software.
StarUML
Ferramenta utilizada na modelagem
dos artefatos visuais do projeto.
Microsoft Word
Ferramenta utilizada para construir a
documentação do projeto.
dados
na
utilizado
codificação
pelo
do
para
Tabela 4 - Recursos de software
2.4.3 Recursos de hardware
Os computadores pessoais de cada integrante foram os únicos recursos
utilizados na construção do projeto. As ferramentas utilizadas por eles para a
integração das atividades fazem ligação direta com a nuvem, não existindo
necessidade de quaisquer recursos adicionais.
12. 3 ANÁLISE E GESTÃO DE RISCOS
Nesta seção serão analisados os riscos potenciais que são prejudiciais para o
andamento do projeto. O objetivo desta análise é conhecer e minimizar, o máximo
possível, a probabilidade de sua ocorrência e o impacto causado por ela, caso venha a
acontecer.
3.1 Riscos do projeto
Segue abaixo tabela com os riscos identificados e sua respectiva classificação,
que visa determinar se a sua ocorrência é geral ou única do projeto:
Risco
Projeto
Ferramentas
de
testes
oferecem pouco suporte à
tecnologia
usada
na
codificação.
Técnico
Negócio
Comum
Especial
X
Tamanho e complexidade do
produto comprometem os
prazos de entrega.
X
Projeto construído sem o
contato
com
possíveis
usuários.
X
Curto
período
para
construção do projeto.
X
X
X
X
a
Equipe não possui tempo
integral disponível.
Funcionalidades codificadas
do zero, sem reutilização.
Equipe pequena.
constante
X
X
X
Equipe
com
pouco
conhecimento
acerca
da
tecnologia
usada
na
codificação.
Necessidade
X
de
X
X
X
X
X
13. aprimoramentos no software.
Dificuldade para solucionar
problemas
encontrados
durante a codificação.
X
X
Tabela 5 - Riscos x Classificação
3.2 Tabela de riscos
A tabela abaixo atribui a cada um dos riscos uma probabilidade, que determina o
grau de chance deste risco acontecer, e um impacto, que determina o nível de desastre
resultante após o efetivo acontecimento deste evento.
Risco
Probabilidade (%)
Impacto
Ferramentas
de
testes
oferecem pouco suporte à
tecnologia
usada
na
codificação.
90%
Catastrófico
Tamanho e complexidade do
produto comprometem os
prazos de entrega.
80%
Crítico
Projeto construído sem o
contato
com
possíveis
usuários.
80%
Crítico
Curto
período
para
construção do projeto.
80%
Crítico
Equipe não possui tempo
integral disponível.
70%
Moderado
Funcionalidades codificadas
do zero, sem reutilização.
70%
Moderado
Equipe pequena.
70%
Marginal
Equipe
com
pouco
conhecimento
acerca
da
tecnologia
usada
na
codificação.
60%
Moderado
a
14. Necessidade constante de
aprimoramentos no software.
50%
Moderado
Dificuldade para solucionar
problemas
encontrados
durante a codificação.
20%
Marginal
Tabela 6 - Análise Risco x Probabilidade x Impacto
3.3 Redução e gestão do risco
riscos
Os quadros abaixo apresentam estratégias para a redução e/ou gestão dos
estudados
anteriormente:
1 - Ferramentas de testes oferecem pouco suporte à tecnologia usada na
codificação.
Probabilidade: 90%.
Impacto: Catastrófico.
Descrição: Ferramentas de testes automatizadas oferecem pouco ou nenhum
suporte à tecnologia usada na codificação do produto.
Estratégia de redução: Minimizar o uso destas ferramentas através da implantação
de outros processos de testes.
Plano de contingência: Dividir os testes complexos em partes mais simples,
facilitando, quando possível, o uso das ferramentas já utilizadas.
Responsável: Kevin Filipe Campos.
Status: Em andamento.
Quadro 1 - Análise do risco 1
2 - Tamanho e complexidade do produto comprometem os prazos de entrega.
Probabilidade: 80%.
Impacto: Crítico.
Descrição: O produto atende a uma necessidade que é bastante simples. No
entanto, devido a quantidade de informações que ele deve gerenciar, seu tamanho e
complexidade crescem demasiadamente, prejudicando os prazos de entrega.
15. Estratégia de redução: Fazer uma análise apurada do escopo e do planejamento
definidos para o projeto.
Plano de contingência: Revisar a documentação escrita para tentar reverter, em
conjunto os possíveis stackholders, os prazos definidos incorretamente. Uma
explicação satisfatória sobre o ocorrido deve ser necessária.
Responsável: Gustavo Souza Santos.
Status: Em andamento.
Quadro 2 - Análise do risco 2
3 - Projeto construído sem o contato com possíveis usuários.
Probabilidade: 80%.
Impacto: Crítico.
Descrição: O projeto foi construído sem a presença de usuários que conhecem as
regras de negócio do ambiente.
Estratégia de redução: Reverter a situação o mais rápido possível, procurando por
possíveis clientes que estejam interessados no produto.
Plano de contingência: Disponibilizar versões de testes para usuários que
conhecem as regras de negócio do ambiente e que podem opinar a respeito do que
está sendo desenvolvido.
Responsável: Gustavo Souza Santos.
Status: Em andamento.
Quadro 3 - Análise do risco 3
4 - Curto período para a construção do projeto.
Probabilidade: 80%.
Impacto: Crítico.
Descrição: Devido a grande carência do mercado, o prazo para construção do
projeto é relativamente curto.
Estratégia de redução: Divisão pertinente das atividades de acordo com com um
planejamento preciso.
16. Plano de contingência: Seguir a risca as informações e prazos detalhados na
especificação do projeto.
Responsável: Onezino Gabriel Moreira.
Status: Em andamento.
Quadro 4 - Análise do risco 4
5 - Equipe não possui tempo integral disponível.
Probabilidade: 70%.
Impacto: Moderado.
Descrição: Devido a outras atividades realizadas por cada integrante da equipe, o
tempo disponível para o projeto não é integral.
Estratégia de redução: Divisão pertinente das atividades de acordo com com um
planejamento de tempo preciso.
Plano de contingência: Rever as atividades realizadas por cada integrante a fim de
não sobrecarregá-lo. A divisão das tarefas entre os membros da equipe deve facilitar
o processo.
Responsável: Tiago Oliveira Santos.
Status: Em andamento.
Quadro 5 - Análise do risco 5
6 - Funcionalidades codificadas do zero, sem reutilização.
Probabilidade: 70%.
Impacto: Moderado.
Descrição: As funcionalidade do software foram desenvolvidas do zero, sem a
utilização/criação de nenhum componente reutilizável.
Estratégia de redução: Adotar medidas que priorizem o desenvolvimento de
componentes reutilizáveis sempre que possível e necessário
Plano de contingência: Modificar as estruturas dos itens que precisam de
reutilização para que se tornem reutilizáveis, evitando a necessidade de replicar
código.
17. Responsável: Tiago Oliveira Santos.
Status: Em andamento.
Quadro 6 - Análise do risco 6
7 - Equipe pequena.
Probabilidade: 70%.
Impacto: Marginal.
Descrição: A equipe responsável pela construção do projeto é relativamente
pequena.
Estratégia de redução: Divisão pertinente das tarefas da equipe de acordo com um
planejamento preciso, combatendo também a sobrecarga de funções.
Plano de contingência: Rever a distribuição de tarefas entre os membros da equipe.
O excesso de funções/atividades deve ser evitado a todo custo.
Responsável: Onezino Gabriel Moreira.
Status: Em andamento.
Quadro 7 - Análise do risco 7
18. 8 - Equipe com pouco conhecimento acerca da tecnologia usada na
codificação.
Probabilidade: 60%.
Impacto: Moderado.
Descrição: A equipe não possui conhecimento aprofundado acerca da tecnologia
utilizada na codificação do projeto.
Estratégia de redução: Buscar métodos que proporcionem novos conhecimentos a
respeito da tecnologia utilizada.
Plano de contingência: Planejar o desenvolvimento de estruturas complexas em
equipe, ao invés de individualmente.
Responsável: Kevin Filipe Campos.
Status: Em andamento.
Quadro 8 - Análise do risco 8
9 - Necessidade constante de aprimoramentos no software.
Probabilidade: 50%.
Impacto: Moderado.
Descrição: Como o software foi desenvolvido sem a presença de um usuário em
potencial, a necessidade de modificações pode ser constante.
Estratégia de redução: Disponibilizar versões de testes para usuários que
conhecem as regras de negócio do ambiente e que podem opinar a respeito do que
está sendo desenvolvido, com o intuito de melhorar as regras de negócio.
Plano de contingência: Planejar as modificações de acordo com as necessidades e
obrigações da equipe.
Responsável: Kevin Filipe Campos.
Status: Em andamento.
Quadro 9 - Análise do risco 9
19. 10 - Dificuldade para solucionar problemas encontrados durante a codificação.
Probabilidade: 20%.
Impacto: Marginal.
Descrição: Devido a complexidade que envolve a tecnologia usada na codificação,
os erros podem levar tempo considerável para serem resolvidos.
Estratégia de redução: Buscar métodos que proporcionem novos conhecimentos a
respeito da tecnologia utilizada.
Plano de contingência: Planejar a solução das pendências em equipe, ao invés de
individualmente.
Responsável: Gustavo Souza Santos.
Status: Em andamento.
Quadro 10 - Análise do risco 10
4 Planejamento Temporal
Nesta seção são definidas as datas de execução das tarefas, bem como seus
responsáveis. No planejamento temporal definimos os marcos e planos de ações. O
cronograma das tarefas está baseado na metodologia aplicada ao projeto e a
mensuração das fases de do projeto de software conforme definimos no item 2.X.X
4.1 Conjunto de Tarefas do Projeto
A definição do conjunto de tarefas de projeto utilizou o modelo iterativo
incremental, como a metodologia encoraja a entrega rápida e constante para utilização
do usuários fizemos marcos de liberação de módulos do produto de software para o
usuário.
O scrum define a divisão das funcionalidades em atividades menores que
podem ser executadas pelo desenvolvedores. Na tabela abaixo está a listagem das
atividades a serem executadas em cada funcionalidade.
Funcionalidade
Funcionalidade
administração
Atividades
de -Desenvolvimento da tela de administração de segurança,
de pessoa e usuários
20. tabelas do sistema
- Desenvolvimento da regra de negócio e persistência das
entidades de usuário e segurança
- Gerar carga inicial dos objetos de segurança, pessoal,
usuário
Manutenção
de - Telas de registro de acervos, de peças e de vinculação de
acervos e peças
peças com o acervo
- Desenvolvimento das regras de negócio e persistência das
entidades acervos e peças
Registro
transação
classificação
de - Tela para registro de transação, classificação de acervo e
e peças
- Desenvolvimento das regras de negócio e persistência das
entidades de transação e classificação.
Tabela 7 – Tabela de Atividades
4.2 Diagrama de Gantt
O diagrama de Gantt nos permite visualizar de forma gráfica o avanço e
planejamento das diferentes etapas de um projeto. A cada inicio e fim da atividade é
mostrado em intervalos.
O detalhamento de nossas atividades no diagrama de Gantt está disponível em:
Figura 5 - Diagrama de Gantt
21. 5.0 ORGANIZAÇÃO DO PESSOAL
5.1 Estrutura da equipe
●
●
●
●
Gerente de Projeto: Onezino Gabriel Moreira
Analista de Sistema: Kevin Filipe
Desenvolvedor: Tiago Oliveira
Analista de Testes: Gustavo Souza
5.2 Mecanismos de comunicação
Os mecanismos de comunicação utilizados serão:
● E-mail - facilidade de comunicação e permite manter o registro das discussões;
● Reuniões diárias - permitem a comunicação face-a-face e ajudam a verificar o
andamento do projeto;
● Ferramentas colaborativas - vários documentos foram editados através do
Google Drive, permitindo a colaboração de todos.
5.3 Uso do Edu-blog como ferramenta de apoio
O blog é uma ferramenta interessante, pois permite que seja disseminado o
conhecimento adquirido durante o projeto, tanto entre os integrantes do projeto quanto
para outras pessoas.
Também ajuda na catalogação das informações mais importantes, criando uma
maneira rápida de se localizar dados importantes mesmo após o fim do projeto.
6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE
DO PRODUTO DE SOFTWARE
● Documentação - A cada etapa do projeto serão produzidos documentos. Estes
serão importantes na elaboração dos testes. Também servirão para guiar o
andamento do projeto. Deverão ser atualizados quando houverem mudanças;
● Testes - Serão elaborados com o auxílio da documentação e executados
durante todas as fases do projeto;
● Controle de versão - Ferramenta que permitirá o rastreamento de alterações e
identificarão os seus autores. Ajudam a manter os documentos atualizados;
● Reuniões diárias - Utilizando a idéia do SCRUM, reuniões diárias de curta
duração serão realizadas para verificar o andamento do projeto.