Plano do projeto de software SIGEM - Sistema de gestão de materiais

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

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

Í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

3

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

4

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

5

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.

6

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.

7

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:

8

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.

9

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

10


Scrum Master Renan Reis Developer1 Katlen Maduro Developer2 Diovane Monteiro Tester Marcos Felipe


Scrum Master Marcos Felipe Developer1 Diovane Monteiro

Developer2 Katlen Maduro Tester Renan Reis


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:

11

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.

12

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

mudanças

X

Uso de metodologias

especiais

X X

Falha na integração com

os demais sistemas

X X

Equipe com comunicação

reduzida

X

Utilização de softwares

nos quais a equipe não

possui nenhuma

experiência

X

13

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.

14

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

a entrega

35% Catastrófico

2 Falta de validação por parte do

usuário final

15% Catastrófico

3 Requisitos voláteis 58% Crítico

4 Requisitos não compreendidos

adequadamente

25% Crítico

5 Afastamento de membro relativo

ao projeto

15% Crítico

6 Dispersão da equipe durante o

projeto

95% Marginal

7 Disponibilidade parcial do tempo 90% Marginal

8 Utilização de tecnologias

recentes

45% Marginal

15

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.

16

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


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.


17

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

18

7. Disponibilidade parcial do tempo


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


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.

19

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

20

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.

21

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.

22

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.

23

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.

24

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.

25

7.1 ANEXOS

Figura 1.1 - Diagrama lógico do sistema SIGEM

26

Figura 1.2 - Modelo EER (Estendido) do sistema SIGEM

27

Figura 1.3 – Diagrama de classes do sistema SIGEM

28

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

29

Figura 1.5 - Tarefas extraídas do redmine

30

Figura 1.6 - Diagrama de Gantt extraído do redmine

31

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.

Plano do projeto de software SIGEM - Sistema de gestão de materiais

Education

Transcript of Plano do projeto de software SIGEM - Sistema de gestão de materiais