Este documento apresenta o plano de projeto de software para produtos da Lacertae SW. Ele descreve o escopo, funcionalidades, requisitos, estimativas, riscos, cronograma e controles de qualidade do projeto de desenvolvimento de um sistema de gestão de materiais para uma universidade.

1. UNIVERSIDADE FEDERAL DO AMAZONAS
INSTITUTO DE COMPUTAÇÃO
PLANO DO PROJETO DE SOFTWARE
PARA PRODUTOS DA LACERTAE SW
Cristina Araújo
Marcos Felipe
MANAUS
2013

2. UNIVERSIDADE FEDERAL DO AMAZONAS
INSTITUTO DE COMPUTAÇÃO
Cristina Araújo
Marcos Felipe
Trabalho apresentado para
graduação em Sistemas de
Informação, com o tema “PLANO DO
PROJETO DE SOFTWARE OO PARA
PRODUTOS DA LACERTAE SW” para
obtenção de nota parcial na
disciplina IEC921 - GERÊNCIA DE
PROJETOS, ministrada pelo Prof.
Rogério Patrício Chagas do
Nascimento.
MANAUS
2013

3. Índice
1. INTRODUÇÃO .................................................................................................... 3
1.1 ÂMBITO DO PROJETO ........................................................................................ 3
1.2 FUNÇÕES PRINCIPAIS DO PRODUTO DE SOFTWARE ............................................... 3
1.3 REQUISITOS COMPORTAMENTAIS OU DE PERFORMANCE ....................................... 5
1.4 GESTÃO E RESTRIÇÕES TÉCNICAS ..................................................................... 6
2. ESTIMATIVAS DO PROJETO ............................................................................ 7
2.1 DADOS HISTÓRICOS UTILIZADOS PARA AS ESTIMATIVAS......................................... 7
2.2 TÉCNICAS DE ESTIMAÇÃO E RESULTADOS ............................................................ 7
2.2.1 TÉCNICA DE ESTIMATIVAS ............................................................................... 7
2.3 RESULTADOS .................................................................................................. 9
2.4 RECURSOS DO PROJETO .................................................................................... 9
2.4.1 RECURSOS HUMANOS .................................................................................... 9
2.4.2 RECURSOS DE SOFTWARE ............................................................................ 10
2.4.3 RECURSOS DE HARDWARE ........................................................................... 11
3. ANÁLISE E GESTÃO DE RISCOS .................................................................. 12
3.1 RISCOS DO PROJETO ....................................................................................... 12
3.2 AVALIAÇÃO GLOBAL DOS RISCOS ...................................................................... 13
3.3 TABELA DE RISCOS .......................................................................................... 14
3.4 REDUÇÃO E GESTÃO DO RISCO ........................................................................ 15
4. PLANEJAMENTO TEMPORAL ........................................................................ 19
4.1 CONJUNTO DE TAREFAS DO PROJETO............................................................... 19
4.2 DIAGRAMA DE GANTT ...................................................................................... 20
5. ORGANIZAÇÃO DO PESSOAL ....................................................................... 21
5.1 ESTRUTURA DA EQUIPE.................................................................................... 21
5.2 MECANISMOS DE COMUNICAÇÃO....................................................................... 22
5.3 USO DO EDU-BLOG COMO FERRAMENTA DE APOIO ............................................. 23
6. PRECAUÇÕES PARA ASSEGURAR E CONTROLAR A QUALIDADE DO
PRODUTO ............................................................................................................ 24
6.1 SEGUIMENTO E CONTROLE DO PROJETO DE SOFTWARE..................................... 24
6.2 REVISÕES TÉCNICAS FORMAIS ......................................................................... 24
6.3 PRODUÇÃO DE DOCUMENTAÇÃO ...................................................................... 24
7.1 ANEXOS ......................................................................................................... 25
REFERÊNCIAS ..................................................................................................... 31

4. 1. Introdução
1.1 Âmbito do Projeto
O Sigem (Sistema de Gestão de Materiais) tem por objetivo o controle de
equipamentos que são emprestados e movimentados entre departamentos. Esses
variam desde computadores e impressoras até placas e equipamentos de menor porte.
Seu objetivo é facilitar os processos de empréstimo e devolução de equipamentos, por
meio de registros como data de entrega e devolução, geração de relatórios e a
documentação necessária, facilitando assim, o trabalho da secretaria e demais
departamentos responsáveis. Como podem ser observados nas Figuras 1.1, 1.2 e 1.3,
em anexos, o diagrama lógico, a modelagem estendida e o diagrama de classes,
respectivamente. Estes demonstram a estrutura do sistema e relacionam o âmbito
descrito anteriormente à um nível mais baixo de abstração.
1.2 Funções principais do produto de software
As principais funcionalidades do Sistema de Gestão de materiais são:
1. Cadastrar Categorias de Equipamento
2. Editar Categorias de Equipamento
3. Excluir Categorias de Equipamento
4. Pesquisar Categorias de Equipamento
5. Cadastrar Projetos
6. Editar Projetos
7. Excluir Projetos
8. Pesquisar Projetos
9. Cadastrar Alunos
3

5. 10. Editar Alunos
11. Excluir Alunos
12. Pesquisar Alunos
13. Cadastrar Equipamento
14. Editar Equipamento
15. Excluir Equipamento
16. Pesquisar Equipamento
17. Efetuar Empréstimo
18. Agendar Empréstimo
19. Efetuar Devolução
20. Gerar Relatórios
O sistema deve permitir as seguintes funcionalidades para seus usuários:
Secretaria
Cadastrar equipamento
Cadastrar curso
Registrar empréstimo
Cadastrar Aluno
Coordenador
Cadastrar projeto
Cadastrar curso
Gerar Relatório
Aprovar empréstimo
Professor
Efetuar empréstimo
Consultar equipamento
Agendar empréstimo
4

6. 1.3 Requisitos comportamentais ou de performance
Disponibilidade:
o O sistema estará em funcionamento 24hs por dia, 7 dias por semana, com paradas
pré-programadas para manutenção.
.
Segurança:
o O sistema não deve permitir acesso por usuários não autorizados.
o Senhas devidamente criptografadas e especificadas por usuários.
Portabilidade:
o O sistema deve ser executado em plataformas Linux(Ou qualquer distribuição Unix)
e Windows, XP ou superior.
o O sistema deve ser compatível com os browsers Mozilla Firefox , Google Chrome,
Opera e Safari. Conforme figura 1.4 em anexos, exibe a tela do sistema.
Eficiência:
o Em condições normais, o sistema deve responder a qualquer requisição no máximo
em 3 segundos, com exceção de processamento de relatórios, aonde o limite
máximo é 6 segundos.
o Em condições de estresse (muitas requisições), o sistema deve responder a
qualquer requisição no máximo em 6 segundos, com exceção de processamento de
relatórios, aonde o limite máximo é 9 segundos.
Integridade:
o O sistema deverá exibir os dados de empréstimos somente para seus respectivos
solicitantes, e a própria secretaria.
o O usuário com perfil de professor somente poderá solicitar equipamentos caso o
mesmo não esteja previamente alocado/reservado em outro projeto.
5

7. o Somente a secretaria poderá registrar os empréstimos e gerar a documentação
necessária para os mesmos.
Usabilidade:
o Interface simples: o sistema exibe uma barra de menu contendo todas as
funcionalidades disponíveis ao usuário.
o A navegabilidade é intuitiva e a disposição dos campos facilita a compreensão e
utilização mesmo para que não possui experiência com o sistema.
1.4 Gestão e Restrições Técnicas
As restrições encontradas na descrição do sistema que poderão limitar o escopo
podem ser:
1. O produto deve ser implementado como uma aplicação web e portável a várias
plataformas;
2. O produto deve ser implementado na linguagem de programação PHP, HTML, jQuery,
utilizando o framework CAKE;
3. O produto deve utilizar Banco de Dados MySQL;
4. Datas de entrega inflexíveis, pois o processo de desenvolvimento ágil (SCRUM), exige
uma apresentação em datas previamente estipuladas;
5. Stakeholders nem sempre presentes para recolhimento de requisitos e validação.
6. Falta de experiência prática com as ferramentas e métodos utilizados para o
desenvolvimento, assim como cronograma curto para desenvolvimento.
6

8. 2. Estimativas do Projeto
As estimativas de projeto aqui apresentadas demonstram a quantidade de tempo
necessário para a execução do projeto. Paralelamente às estimativas baseadas na
métrica da Lacertae Software, Lorenz &Kidd (orientada a classes), estão listadas de
forma a comparar os dados das estimativas com os calculados (dados reais do projeto).
É possível verificar que houve várias diferenças em relação ao que foi estimado
inicialmente, e o que ocorreu de fato. Pode-se dar ênfase à tarefa de codificação, que
foi estipulado em um nível inferior se relacionado com os dados reais.
.
2.1 Dados históricos utilizados para as estimativas
Levando em consideração projetos semelhantes, pode-se considerar o primeiro
projeto com maior detalhamento relacionado à estimativas de tempo e uso da
ferramenta, assim como análise de riscos.
2.2 Técnicas de estimação e resultados
Para encontrar o tempo, aplicou-se uma técnica de estimativa, a qual foi indicada
na disciplina de gerência de projetos. Neste caso iremos utilizar a métrica adotada pela
Lacertae Software, Lorenz &Kidd (orientada a classes).
2.2.1 Técnica de estimativas
Com a aplicação da métrica de Lorenz &Kidd definida pela Lacertae Software, os
seguintes resultados foram obtidos:
7

9. O número de classes chaves do projeto são 3.
Como o projeto é um sistema para ambiente WEB, utilizará interface GUI complexa,
dessa forma o fator multiplicador será 3.
O número de classes de suporte pode ser encontrado a partir do número de classes
chave x multiplicador, dessa forma, 3 x 3 = 9 classes de suporte.
O total de classes do projeto será número de classes chave + número de classes
de suporte, onde 3 + 9 = 12 classes.
Parte da equipe não possui muita experiência com projetos relacionados, então
chegou-se à um número de aproximados 16 dias-pessoa.
O cálculo do esforço estimado: 12 classes x 16 dias-pessoa, onde obtém-se 192
dias de trabalho.
Considerando 4 pessoas envolvidas no projeto e 22 dias úteis de trabalho por mês
=> 192/4 = 48 dias, aproximadamente 1,6 meses
Considerando que os dias de trabalho totais são 192 dias, esses dias agora são
distribuídos de acordo com as seguintes porcentagens de distribuição dos componentes
essenciais no projeto, sugeridas pela Lacertae Software:
Estimativa Realizado
Planejamento 20% 5%
Análise e Projeto 20% 15%
Geração de Código 20% 52%
Testes 40% 28%
Na tabela acima, a estimativa é realizada com base nos cálculos sugeridos pela
metodologia da Lacertae Software, e ao lado, o Realizado é calculado com base nas
tarefas efetuadas ao longo das Sprints. Os dados do Realizado foram retirados do
Redmine, referenciado em anexos, na figura 1.5.
8

10. 2.3 Resultados
1) Planejamento: 192 * 20% = 38,4 dias de trabalho
2) Análise e Projeto: 192 * 20% = 38,4 dias de trabalho
3) Testes: 192 * 40% = 76,8 dias de trabalho
4) Geração de código: 192 * 20% = 38,4 dias de trabalho
2.4 Recursos do projeto
A aplicabilidade dos recursos do projeto são evidenciados no restante do
documento, nas sessões aonde são exibidas as ferramentas e recursos relacionados
entre eles, recursos humanos e tecnológicos.
2.4.1 Recursos Humanos
De acordo com a metodologia ágil, onde as funções mudam conforme as sprints,
o projeto de Gerenciamento de Projetos de Pesquisa e Desenvolvimento contará com
quatro pessoas que exercerão os diversos papéis necessários à execução, conforme
descrito a seguir:
Sprint 1 Período: 07/01 à 23/01
Scrum Master Katlen Maduro
Developer1 Marcos Felipe
Developer2 Renan Reis
Tester Diovane
9

11. Sprint 2 Período: 28/01 à 20/02
Scrum Master Renan Reis
Developer1 Katlen Maduro
Developer2 Diovane Monteiro
Tester Marcos Felipe
Sprint 3 Período: 25/02 à 13/03
Scrum Master Marcos Felipe
Developer1 Diovane Monteiro
Developer2 Katlen Maduro
Tester Renan Reis
Sprint 4 Período: 18/03 à 03/04
Scrum Master Diovane Monteiro
Developer1 Renan Reis
Developer2 Marcos Felipe
Tester Katlen Maduro
2.4.2 Recursos de Software
O projeto irá usufruir dos seguintes softwares para composição do produto de
software, além do projeto de gerência de produção:
10

12. Wamp – Composto do módulo Apache e MySQL, responsável pelo serviço de
transação de dados para a Web e gerenciamento da base de dados do software.
Eclipse SR2 – IDE a ser utilizada na implementação do produto de software final.
PHP –linguagem de programação a ser utilizada para o desenvolvimento do software
final.
CAKE PHP – Framework escrito em PHP que tem como principais objetivos oferecer
uma estrutura que possibilite aos programadores de PHP de todos os níveis
desenvolverem aplicações robustas rapidamente, sem perder flexibilidade, utilizado
conjuntamente com MVC.
Microsoft Word– Editor de texto usados na documentação, relatórios e documentos
afins.
Microsoft Excel – Planilha eletrônica usada para criar o product backlog e manter
controle sobre determinadas modificações.
MSProject – Software gerenciador de projetos que servirá de base para gestão
atualizada e confiável do projeto do produto.
2.4.3 Recursos de Hardware
Para documentação, implementação e gestão do projeto de software, nossos
recursos iniciais de hardware estão agrupados em quatro notebooks, além do recurso
das nuvens, em servidores externos.
11

13. 3. Análise e Gestão de Riscos
Esta análise consiste em uma série de passos que permitem compreender e
gerir os riscos que podem ocorrer no projeto. Desta forma, os riscos foram identificados,
avaliados quanto à probabilidade de ocorrência e estimados segundo o seu impacto no
projeto de software para administrá-los corretamente.
3.1 Riscos do projeto
Os riscos do projeto que foram identificados e necessitam ser monitorados
durante o projeto são:
Risco Projeto Técnico Negócio Comum Especial
Equipamento indisponível X
Requisitos em constante X
mudanças
Uso de metodologias X X
especiais
Falha na integração com X X
os demais sistemas
Equipe com comunicação X
reduzida
Utilização de softwares X
nos quais a equipe não
possui nenhuma
experiência
12

14. 3.2 Avaliação global dos riscos
1. O Gestor de Software dá suporte ao projeto?
R: Confere. No caso do gestor, o mesmo participa do processo de forma ativa, por
isso existe suporte ao projeto.
1. Os Clientes estão entusiasmados com o projeto e o produto?
R: Os usuários em geral, assim como o cliente, estão entusiasmados e possuem
expectativas acerca do projeto, que auxiliará no processo de empréstimo e controle de
equipamentos.
2. Os Engenheiros de Software compreenderam bem os requisitos?
R: Os requisitos foram bem definidos e o escopo pode ser considerado pequeno, porém
com várias alterações na medida em que outros stakeholders estejam envolvidos.
3. Os Clientes estiveram envolvidos na definição dos requisitos?
R: Em maior parte do projeto. Porém a partir da Sprint 3, houve o envolvimento de mais
stakeholders, o que acarretou em mais requisitos gerados.
4. O âmbito do projeto é estável?
R: O âmbito do projeto está fixo e condizente com a ideia inicial.
5. Os engenheiros de software têm as competências requeridas?
R: A maior parte dos engenheiros possui a competência necessária para desenvolver o
projeto.
6. Os requisitos do projeto são estáveis?
R: Não há estabilidade relacionada aos requisitos do projeto, visto que ocorreram várias
mudanças no decorrer do mesmo.
13

15. 7. A equipe de desenvolvimento tem experiência na tecnologia a implementar?
R: Sim. A equipe possui experiência na tecnologia em questão.
8. É adequado o número de pessoas da equipe de trabalho?
R: Mesmo a equipe possuindo todos os integrantes, para o escopo determinado, seriam
necessários mais integrantes para se manter a qualidade, escopo e prazo, na forma em
que foram determinados.
3.3 Tabela de riscos
Conforme os riscos identificados, abaixo serão apresentados a sua probabilidade
de ocorrência e impacto esperado no projeto.
Nº Risco Probabilidade Impacto
1 Exceder o prazo estipulado para 35% Catastrófico
a entrega
2 Falta de validação por parte do 15% Catastrófico
usuário final
3 Requisitos voláteis 58% Crítico
4 Requisitos não compreendidos 25% Crítico
adequadamente
5 Afastamento de membro relativo 15% Crítico
ao projeto
6 Dispersão da equipe durante o 95% Marginal
projeto
7 Disponibilidade parcial do tempo 90% Marginal
8 Utilização de tecnologias 45% Marginal
recentes
14

16. 3.4 Redução e Gestão do Risco
Para garantir as estratégias de redução, supervisão e gestão dos riscos (RSGR)
identificados, estão descrito abaixo os principais:
1. Exceder o prazo estipulado para a entrega
Probabilidade: 35% Impacto: Catastrófico
Descrição: O prazo estimado para o projeto é suficiente, porém o escopo é volátil e,
portanto, a estimativa pode estar equivocada.
Estratégia de redução: A realização de acompanhamento e atualização da
documentação.
Plano de Contingência: Focar no desenvolvimento e possível entrega das funções e
módulos essenciais para o funcionamento do sistema, além de negociar com o
cliente quanto à uma possível extensão do prazo.
Responsável: Marcos Felipe
2. Falta de validação por parte do usuário final
Probabilidade: 15% Impacto: Catastrófico
Descrição: Ocorreram de fato mudanças, devido aos principais stakeholders terem
sido entrevistados no meio do projeto, visto que não era possível entrevistá-los antes,
devido a problemas de comunicação.
Estratégia de redução: Realizar reuniões periódicas com parte dos envolvidos para
esclarecer requisitos e regras de negócio conforme o projeto é desenvolvido .
15

17. Plano de Contingência: Replanejar parte das atividades para se adequar aos novos
requisitos do projeto
Responsável: Diovane Monteiro
Status: Em andamento
3. Requisitos voláteis
Probabilidade: 58% Impacto: Crítico
Descrição: Ocorreram de fato mudanças, devido aos principais stakeholders terem
sido entrevistados no meio do projeto, visto que não era possível entrevistá-los antes,
devido a problemas de comunicação.
Estratégia de redução: A realização de reuniões com stakeholders
Plano de Contingência: Replanejar parte das atividades para se adequar aos novos
requisitos do projeto
Responsável: Diovane Monteiro
Status: Em andamento
4. Requisitos não compreendidos adequadamente
Probabilidade: 25% Impacto:Crítico
Descrição:Nem todos os requisitos foram adequadamente capturados durante o
processo de elicitação, assim como na adoção da metodologia Scrum.
Estratégia de redução: Reuniões constantes com os integrantes e o ProductOwner,
com a finalidade de sanar dúvidas relacionadas ao requisitos, mapeamento dos
mesmo e criação do backlog.
Plano de Contingência: Analisar os documentos gerados pelas reuniões e reaver os
conceitos relacionados aos requisitos do sistema.
Responsável: Diovane Monteiro
16

18. 5. Afastamento de membro relativo ao projeto
Probabilidade: 15% Impacto: Crítico
Descrição: Os integrantes do projeto são, em sua maioria, assíduos e
compromissados com o trabalho, porém por motivos de saúde e/ou locomoção, a
ausência em determinadas fases do projeto são plausíveis.
Estratégia de redução: Distribuição das atividades do membro em questão para os
demais da equipe, assim como mudanças na prioridade do escopo.
Plano de Contingência: No caso do afastamento ou abandono deste membro da
equipe, todas suas tarefas deverão ser redistribuídas e replanejadas.
Responsável: Renan Reis
6. Dispersão da equipe durante o projeto
Probabilidade: 95% Impacto:Marginal
Descrição: A dispersão dos membros da equipe está relacionada ao tempo
disponível para se dedicar ao projeto, assim como o tempo possível para reuniões
“cara a cara” e afins.
Estratégia de redução: Distribuição das funções dos membros da equipe, de forma
que cada papel específico possa gerar ao final de cada tarefa o status relacionado,
criando assim controle sobre o andamento das tarefas.
Plano de Contingência: Criar meios para interação assíncrona entre os integrantes
da equipe, amenizando assim o impacto da dispersão.
Responsável: Renan Reis
17

19. 7. Disponibilidade parcial do tempo
Probabilidade: 90% Impacto:Marginal
Descrição:O tempo disponível para dedicação do projeto é parcialmente
aproveitado, visto que nenhum dos integrantes possui tempo integral para dedicação
ao mesmo.
Estratégia de redução: Iniciar o planejamento de atividades da forma identificada
como ideal para a divisão de tempo e aproveitamento da disponibilidade de cada
integrante.
Plano de Contingência: Criar meios em que a equipe possa trabalhar de forma
dessincronizada e em tempo disponível.
Responsável: Katlen Maduro
Status: Risco ocorreu de fato. O Planejamento das atividades foram realizadas para
alguns membros da equipe. Várias tarefas foram afetadas por atrasos e
consequentemente repassadas para outras Sprints.
8. Utilização de tecnologias recentes
Probabilidade: 45% Impacto:Marginal
Descrição: Parte dos membros não possuía experiência nas ferramentas e
tecnologias utilizadas
Estratégia de redução: Induzir os membros com menos experiência ao aprendizado
das tecnologias com outros membros que já possuem mais experiência.
Plano de Contingência: Criar um programa de treinamento para a tecnologia
solicitada.
Responsável: Marcos Felipe
Status: Risco ocorreu de fato. Alguns integrantes da equipe necessitaram de um
treinamento prévio nas tecnologias empregadas.
18

20. 4. Planejamento Temporal
No Planejamento Temporal são definidas as datas de execução das tarefas
assim como, os responsáveis por cada uma delas através do Diagrama de Gantt, o qual
foi elaborado em cada Sprint por determinado Scrum Master, dentro do projeto.
4.1 Conjunto de Tarefas do Projeto
Aqui são apresentados o Modelo de Processo escolhido e as suas atividades e
tarefas que foram escolhidas para serem apresentadas nesta seção.
Com base nos cálculos descritos na seção 2 presente no item 2.3 (Resultados), o
esforço estimado para a realização do projeto é de 192 dias trabalhados, demonstrados
na tabela abaixo, divididos por fases que vão desde o planejamento até os testes.
Fase Projeto Cálculo Dias Trabalhados
Planejamento 20% 192X20% 38,4
Análise requisitos 20% 192X20% 38,4
Geração de Código 20% 192X20% 38,4
Testes 40% 192X40% 76,8
TOTAL 192
19

21. 4.2 Diagrama de Gantt
O diagrama de Gantt é um gráfico usado para ilustrar o avanço das diferentes
etapas de um projeto. Os intervalos de tempo representando o início e fim de cada fase
aparecem como barras coloridas sobre o eixo horizontal do gráfico. [2]
Na seção de anexos, se encontra o diagrama de Gantt exibido em quatro etapas,
representados pelas SPRINTS decorrentes. O diagrama foi gerado a partir das tarefas
registradas no redmine, sendo estes referentes às quatro Sprints, de acordo com as
Figuras 1.6 e 1.5 em anexos, aonde são exibidos o diagrama e as tarefas,
respectivamente.
20

22. 5. Organização do Pessoal
A organização pessoal se baseou em encontros com a equipe, além de
comunicação via e-mail, gtalk, dentre outros meios possíveis, para que o projeto
pudesse ocorrer em paralelo à outras atividades exercidas pelos membros da equipe.
5.1 Estrutura da equipe
A equipe possui uma estrutura composta com 4 integrantes. O modelo Ágil
exigirá reunião diária, a revisão das metas a cada final da sprint, analisando as tarefas
e atrasos em retrospectiva para aprimoramento das metas. Os papéis descritos são:
Scrum Master, Developer1, Developer2 e Tester, sendo o ProductOwner o Prof Dr.
Arilo Dias. A disposição dos integrantes, relacionados a seus respectivos papéis, são
modificados a cada Sprint.
Scrum Master
O Scrum Master caracteriza-se como o responsável pelo incentivo à equipe, com
a tarefa de remover possíveis impedimentos que influenciem na parte operacional, além
de ser o responsável pelo registro de determinadas atividades da Sprint. Vale ressaltar
que o Scrum Master não é o líder da equipe, somenete exerce a função de apoio.
Desenvolvedores
Desenvolvedores são os membros com todas as habilidades necessárias para
transformar os requisitos do ProductOwner em um pedaço potencialmente distribuível
do produto ao final da Sprint.
ProductOwner
O ProductOwner é a única pessoa responsável pelo gerenciamento do Backlog
do Produto e por garantir o valor do trabalho realizado pelo Time Scrum, garantindo que
seja visível para todos da equipe.
21

23. Tester ou Testador
O Tester faz a integração com a equipe de análise e desenvolvimento
procurando entender as regras de negócio, arquitetura e funcionamento das atividades
no sistema para validar o sistema.
5.2 Mecanismos de comunicação
Redmine
Redmine é um software livre e de código aberto para gerenciamento de projetos.
Foi desenvolvido na linguagem Ruby utilizando framework Ruby on Rails. Redmine é
uma ferramenta multi-plataforma que suporta vários bancos de dados, extensões de
plugins e sistema de controle de versão. [3]
Nele os documentos foram centrados para consulta da equipe por todos os
envolvidos e para acompanhamento de mudanças na documentação relacionado ao
projeto.
E-mail e Chats
Um meio importante para comunicação entre a equipe se baseou em e-mails e
chats, aonde 90% da iteração entre os integrantes foi efetuada.
Aplicativos (Whatsapp)
Outros meios que foram utilizados para comunicação, são aplicativos para
smartphones, com a criação de grupos nos mesmos.
22

24. 5.3 Uso do Edu-blog como ferramenta de apoio [1]
A utilização do Edu-blog como ferramenta de apoio foi de grande valia para
complementação dos trabalhos aqui desenvolvidos, assim como o mesmo agrega valor
aos conhecimentos que são exibidos na ferramenta.
Pelo fato da ferramenta ser multiplataforma, seu fácil entendimento em questão
de navegabilidade e seu conteúdo formam uma rede de conhecimento de grande valia
para seus visitantes e utilizadores, assim como um guia eficaz para o assunto em que é
proposto. Durante o processo de desenvolvimento da documentação relacionada ao
projeto, a ferramenta Edu-blog influenciou de maneira positiva, como um guia durante o
desenvolvimento, assim constituindo de forma eficaz o processo como um todo.
23

25. 6. Precauções para assegurar e controlar a qualidade do produto
Para assegurar a qualidade de produto, existe o processo de teste do mesmo,
sendo este executado durante e ao final de cada Sprint, garantindo assim que o
sistema está funcionando de forma devida. Para saber se o sistema atende o requisito
do usuário, revisões a cada Sprint, juntamente com os envolvidos, são uma forma de
garantir a qualidade e assegurar que o escopo é válido.
6.1 Seguimento e Controle do Projeto de Software
É realizado um acompanhamento constante das atividades desenvolvidas por
parte de todos os envolvidos no projeto e principalmente validação com o cliente.
6.2 Revisões Técnicas Formais
As revisões são realizadas na etapa de Análise e Projeto, visando à identificação
de erros nas fases iniciais do projeto, onde o custo para a manutenção é menor.
6.3 Produção de Documentação
Para o controle de qualidade do processo de desenvolvimento, foi elaborada
documentação nas etapas de Análise, Projeto e Teste em todo o processo de execução
do projeto.
24

26. 7.1 ANEXOS
Figura 1.1 - Diagrama lógico do sistema SIGEM
25

27. Figura 1.2 - Modelo EER (Estendido) do sistema SIGEM
26

28. Figura 1.3 – Diagrama de classes do sistema SIGEM
27

29. Figura 1.4 - Tela visualização de equipamentos do sistema SIGEM
28

30. Figura 1.5 - Tarefas extraídas do redmine
29

31. Figura 1.6 - Diagrama de Gantt extraído do redmine
30

32. Referências
[1] - Edu Blog- Informações à respeito da documentação. Disponível em: http://gp-ufam-
2012.blogspot.com.br. Acesso em: 17 de mar. 2013.
[2] - Redmine - Diagrama de Gantt e tarefas das Sprints. Disponível em:
http://redmine.icomp.ufam.edu.br/projects/b/issues/gantt. Acesso em: 20 de mar. 2013.
[3] - Viva o Linux – Informações sobre o Redmine. Disponível em:
http://www.vivaolinux.com.br/artigo/Gerencia-de-projetos-com-Redmine/. Acesso em:
14 de mar. 2013.
31