UNIVERSIDADE FEDERAL DO AMAZONAS INSTITUTO DE COMPUTAO

PLANO DO PROJETO DE SOFTWARE PARA PRODUTOS DA LACERTAE SW

Cristina Arajo Marcos Felipe

MANAUS 2013

UNIVERSIDADE FEDERAL DO AMAZONAS INSTITUTO DE COMPUTAO

Cristina Arajo Marcos Felipe

Trabalho apresentado para graduao em Sistemas de Informao, com o tema PLANO DO PROJETO DE SOFTWARE OO PARA PRODUTOS DA LACERTAE SW para obteno de nota parcial na disciplina IEC921 - GERNCIA DE PROJETOS, ministrada pelo Prof. Rogrio Patrcio Chagas do Nascimento.

MANAUS 2013

ndice

1. INTRODUO .................................................................................................... 3 1.1 MBITO DO PROJETO ........................................................................................ 3 1.2 FUNES PRINCIPAIS DO PRODUTO DE SOFTWARE ............................................... 3 1.3 REQUISITOS COMPORTAMENTAIS OU DE PERFORMANCE ....................................... 5 1.4 GESTO E RESTRIES TCNICAS ..................................................................... 6 2. ESTIMATIVAS DO PROJETO ............................................................................ 7 2.1 DADOS HISTRICOS UTILIZADOS PARA AS ESTIMATIVAS......................................... 7 2.2 TCNICAS DE ESTIMAO E RESULTADOS ............................................................ 7 2.2.1 TCNICA 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. ANLISE E GESTO DE RISCOS .................................................................. 12 3.1 RISCOS DO PROJETO ....................................................................................... 12 3.2 AVALIAO GLOBAL DOS RISCOS ...................................................................... 13 3.3 TABELA DE RISCOS .......................................................................................... 14 3.4 REDUO E GESTO DO RISCO ........................................................................ 15 4. PLANEJAMENTO TEMPORAL ........................................................................ 19 4.1 CONJUNTO DE TAREFAS DO PROJETO............................................................... 19 4.2 DIAGRAMA DE GANTT ...................................................................................... 20 5. ORGANIZAO DO PESSOAL ....................................................................... 21 5.1 ESTRUTURA DA EQUIPE.................................................................................... 21 5.2 MECANISMOS DE COMUNICAO....................................................................... 22 5.3 USO DO EDU-BLOG COMO FERRAMENTA DE APOIO ............................................. 23 6. PRECAUES PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO ............................................................................................................ 24 6.1 SEGUIMENTO E CONTROLE DO PROJETO DE SOFTWARE..................................... 24 6.2 REVISES TCNICAS FORMAIS ......................................................................... 24 6.3 PRODUO DE DOCUMENTAO ...................................................................... 24 7.1 ANEXOS ......................................................................................................... 25 REFERNCIAS ..................................................................................................... 31

1. Introduo

1.1 mbito do Projeto

O Sigem (Sistema de Gesto de Materiais) tem por objetivo o controle de equipamentos que so emprestados e movimentados entre departamentos. Esses variam desde computadores e impressoras at placas e equipamentos de menor porte. Seu objetivo facilitar os processos de emprstimo e devoluo de equipamentos, por meio de registros como data de entrega e devoluo, gerao de relatrios e a documentao necessria, facilitando assim, o trabalho da secretaria e demais departamentos responsveis. Como podem ser observados nas Figuras 1.1, 1.2 e 1.3, em anexos, o diagrama lgico, a modelagem estendida e o diagrama de classes, respectivamente. Estes demonstram a estrutura do sistema e relacionam o mbito descrito anteriormente um nvel mais baixo de abstrao.

1.2 Funes principais do produto de software

As principais funcionalidades do Sistema de Gesto de materiais so:

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

10. Editar Alunos 11. Excluir Alunos 12. Pesquisar Alunos 13. Cadastrar Equipamento 14. Editar Equipamento 15. Excluir Equipamento 16. Pesquisar Equipamento 17. Efetuar Emprstimo 18. Agendar Emprstimo 19. Efetuar Devoluo 20. Gerar Relatrios O sistema deve permitir as seguintes funcionalidades para seus usurios: Secretaria Cadastrar equipamento Cadastrar curso Registrar emprstimo Cadastrar Aluno Coordenador Cadastrar projeto Cadastrar curso Gerar Relatrio Aprovar emprstimo Professor Efetuar emprstimo Consultar equipamento Agendar emprstimo

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 manuteno. . Segurana: o O sistema no deve permitir acesso por usurios no autorizados.
o

Senhas devidamente criptografadas e especificadas por usurios.

Portabilidade: o O sistema deve ser executado em plataformas Linux(Ou qualquer distribuio Unix) e Windows, XP ou superior.
o

O sistema deve ser compatvel com os browsers Mozilla Firefox , Google Chrome, Opera e Safari. Conforme figura 1.4 em anexos, exibe a tela do sistema.

Eficincia: o Em condies normais, o sistema deve responder a qualquer requisio no mximo em 3 segundos, com exceo de processamento de relatrios, aonde o limite mximo 6 segundos.
o

Em condies de estresse (muitas requisies), o sistema deve responder a qualquer requisio no mximo em 6 segundos, com exceo de processamento de relatrios, aonde o limite mximo 9 segundos.

Integridade: o O sistema dever exibir os dados de emprstimos somente para seus respectivos solicitantes, e a prpria secretaria. o O usurio com perfil de professor somente poder solicitar equipamentos caso o mesmo no esteja previamente alocado/reservado em outro projeto.
5

Somente a secretaria poder registrar os emprstimos e gerar a documentao necessria para os mesmos.

Usabilidade: o Interface simples: o sistema exibe uma barra de menu contendo todas as funcionalidades disponveis ao usurio.
o

A navegabilidade intuitiva e a disposio dos campos facilita a compreenso e utilizao mesmo para que no possui experincia com o sistema.

1.4 Gesto e Restries Tcnicas

As restries encontradas na descrio do sistema que podero limitar o escopo podem ser: 1. O produto deve ser implementado como uma aplicao web e portvel a vrias plataformas; 2. O produto deve ser implementado na linguagem de programao PHP, HTML, jQuery, utilizando o framework CAKE; 3. O produto deve utilizar Banco de Dados MySQL; 4. Datas de entrega inflexveis, pois o processo de desenvolvimento gil (SCRUM), exige uma apresentao em datas previamente estipuladas;
5. 6.

Stakeholders nem sempre presentes para recolhimento de requisitos e validao. Falta de experincia prtica com as ferramentas e mtodos utilizados para o desenvolvimento, assim como cronograma curto para desenvolvimento.

2. Estimativas do Projeto As estimativas de projeto aqui apresentadas demonstram a quantidade de tempo necessrio para a execuo do projeto. Paralelamente s estimativas baseadas na mtrica da Lacertae Software, Lorenz &Kidd (orientada a classes), esto listadas de forma a comparar os dados das estimativas com os calculados (dados reais do projeto). possvel verificar que houve vrias diferenas em relao ao que foi estimado inicialmente, e o que ocorreu de fato. Pode-se dar nfase tarefa de codificao, que foi estipulado em um nvel inferior se relacionado com os dados reais. .

2.1 Dados histricos utilizados para as estimativas

Levando em considerao projetos semelhantes, pode-se considerar o primeiro projeto com maior detalhamento relacionado estimativas de tempo e uso da ferramenta, assim como anlise de riscos.

2.2 Tcnicas de estimao e resultados

Para encontrar o tempo, aplicou-se uma tcnica de estimativa, a qual foi indicada na disciplina de gerncia de projetos. Neste caso iremos utilizar a mtrica adotada pela Lacertae Software, Lorenz &Kidd (orientada a classes).

2.2.1 Tcnica de estimativas

Com a aplicao da mtrica de Lorenz &Kidd definida pela Lacertae Software, os seguintes resultados foram obtidos:

O nmero de classes chaves do projeto so 3. Como o projeto um sistema para ambiente WEB, utilizar interface GUI complexa, dessa forma o fator multiplicador ser 3. O nmero de classes de suporte pode ser encontrado a partir do nmero de classes chave x multiplicador, dessa forma, 3 x 3 = 9 classes de suporte. O total de classes do projeto ser nmero de classes chave + nmero de classes de suporte, onde 3 + 9 = 12 classes. Parte da equipe no possui muita experincia com projetos relacionados, ento chegou-se um nmero de aproximados 16 dias-pessoa. O clculo do esforo estimado: 12 classes x 16 dias-pessoa, onde obtm-se 192 dias de trabalho. Considerando 4 pessoas envolvidas no projeto e 22 dias teis de trabalho por ms => 192/4 = 48 dias, aproximadamente 1,6 meses Considerando que os dias de trabalho totais so 192 dias, esses dias agora so distribudos de acordo com as seguintes porcentagens de distribuio dos componentes essenciais no projeto, sugeridas pela Lacertae Software: Estimativa Planejamento Anlise e Projeto Gerao de Cdigo Testes 20% 20% 20% 40% Realizado 5% 15% 52% 28%

Na tabela acima, a estimativa realizada com base nos clculos 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.

2.3 Resultados

1) Planejamento: 192 * 20% = 38,4 dias de trabalho 2) Anlise e Projeto: 192 * 20% = 38,4 dias de trabalho 3) Testes: 192 * 40% = 76,8 dias de trabalho 4) Gerao de cdigo: 192 * 20% = 38,4 dias de trabalho

2.4 Recursos do projeto

A aplicabilidade dos recursos do projeto so evidenciados no restante do documento, nas sesses aonde so exibidas as ferramentas e recursos relacionados entre eles, recursos humanos e tecnolgicos.

2.4.1 Recursos Humanos

De acordo com a metodologia gil, onde as funes mudam conforme as sprints, o projeto de Gerenciamento de Projetos de Pesquisa e Desenvolvimento contar com quatro pessoas que exercero os diversos papis necessrios execuo, conforme descrito a seguir:

Sprint 1
Scrum Master Developer1 Developer2 Tester

Perodo: 07/01 23/01 Katlen Maduro Marcos Felipe Renan Reis Diovane
9

Sprint 2
Scrum Master Developer1 Developer2 Tester

Perodo: 28/01 20/02 Renan Reis Katlen Maduro Diovane Monteiro Marcos Felipe

Sprint 3
Scrum Master Developer1 Developer2 Tester

Perodo: 25/02 13/03 Marcos Felipe Diovane Monteiro Katlen Maduro Renan Reis

Sprint 4
Scrum Master Developer1 Developer2 Tester

Perodo: 18/03 03/04 Diovane Monteiro Renan Reis Marcos Felipe Katlen Maduro

2.4.2 Recursos de Software

O projeto ir usufruir dos seguintes softwares para composio do produto de software, alm do projeto de gerncia de produo:

10

Wamp Composto do mdulo Apache e MySQL, responsvel pelo servio de transao de dados para a Web e gerenciamento da base de dados do software. Eclipse SR2 IDE a ser utilizada na implementao do produto de software final. PHP linguagem de programao 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 nveis desenvolverem aplicaes robustas rapidamente, sem perder flexibilidade, utilizado conjuntamente com MVC. Microsoft Word Editor de texto usados na documentao, relatrios e documentos afins. Microsoft Excel Planilha eletrnica usada para criar o product backlog e manter controle sobre determinadas modificaes. MSProject Software gerenciador de projetos que servir de base para gesto atualizada e confivel do projeto do produto.

2.4.3 Recursos de Hardware

Para documentao, implementao e gesto do projeto de software, nossos recursos iniciais de hardware esto agrupados em quatro notebooks, alm do recurso das nuvens, em servidores externos.

11

3. Anlise e Gesto de Riscos

Esta anlise consiste em uma srie de passos que permitem compreender e gerir os riscos que podem ocorrer no projeto. Desta forma, os riscos foram identificados, avaliados quanto probabilidade de ocorrncia 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 so:

Risco Equipamento indisponvel Requisitos em constante mudanas Uso de metodologias

Projeto

Tcnico X

Negcio

Comum

Especial

especiais Falha na integrao com os demais sistemas Equipe com comunicao reduzida Utilizao de softwares X X X X

nos quais a equipe no possui experincia nenhuma

12

3.2 Avaliao 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 esto entusiasmados com o projeto e o produto? R: Os usurios em geral, assim como o cliente, esto entusiasmados e possuem expectativas acerca do projeto, que auxiliar no processo de emprstimo 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, porm com vrias alteraes na medida em que outros stakeholders estejam envolvidos.

3. Os Clientes estiveram envolvidos na definio dos requisitos? R: Em maior parte do projeto. Porm a partir da Sprint 3, houve o envolvimento de mais stakeholders, o que acarretou em mais requisitos gerados.

4. O mbito do projeto estvel? R: O mbito do projeto est fixo e condizente com a ideia inicial. 5. Os engenheiros de software tm as competncias requeridas? R: A maior parte dos engenheiros possui a competncia necessria para desenvolver o projeto.

6. Os requisitos do projeto so estveis? R: No h estabilidade relacionada aos requisitos do projeto, visto que ocorreram vrias mudanas no decorrer do mesmo.

13

7. A equipe de desenvolvimento tem experincia na tecnologia a implementar? R: Sim. A equipe possui experincia na tecnologia em questo.

8. adequado o nmero de pessoas da equipe de trabalho? R: Mesmo a equipe possuindo todos os integrantes, para o escopo determinado, seriam necessrios 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 sero apresentados a sua probabilidade de ocorrncia e impacto esperado no projeto. N 1 Risco Exceder o prazo estipulado para a entrega 2 Falta de validao por parte do usurio final 3 4 Requisitos volteis Requisitos no compreendidos adequadamente 5 Afastamento de membro relativo ao projeto 6 Disperso da equipe durante o projeto 7 8 Disponibilidade parcial do tempo Utilizao recentes de tecnologias 90% 45% Marginal Marginal 95% Marginal 15% Crtico 58% 25% Crtico Crtico 15% Catastrfico Probabilidade 35% Impacto Catastrfico

14

3.4 Reduo e Gesto do Risco

Para garantir as estratgias de reduo, superviso e gesto dos riscos (RSGR) identificados, esto descrito abaixo os principais:

1. Exceder o prazo estipulado para a entrega Probabilidade: 35% Impacto: Catastrfico

Descrio: O prazo estimado para o projeto suficiente, porm o escopo voltil e, portanto, a estimativa pode estar equivocada. Estratgia de reduo: A realizao de acompanhamento e atualizao da documentao. Plano de Contingncia: Focar no desenvolvimento e possvel entrega das funes e mdulos essenciais para o funcionamento do sistema, alm de negociar com o cliente quanto uma possvel extenso do prazo. Responsvel: Marcos Felipe

2. Falta de validao por parte do usurio final Probabilidade: 15% Impacto: Catastrfico

Descrio: Ocorreram de fato mudanas, devido aos principais stakeholders terem sido entrevistados no meio do projeto, visto que no era possvel entrevist-los antes, devido a problemas de comunicao. Estratgia de reduo: Realizar reunies peridicas com parte dos envolvidos para esclarecer requisitos e regras de negcio conforme o projeto desenvolvido .
15

Plano de Contingncia: Replanejar parte das atividades para se adequar aos novos requisitos do projeto Responsvel: Diovane Monteiro Status: Em andamento

3. Requisitos volteis Probabilidade: 58% Impacto: Crtico

Descrio: Ocorreram de fato mudanas, devido aos principais stakeholders terem sido entrevistados no meio do projeto, visto que no era possvel entrevist-los antes, devido a problemas de comunicao. Estratgia de reduo: A realizao de reunies com stakeholders Plano de Contingncia: Replanejar parte das atividades para se adequar aos novos requisitos do projeto Responsvel: Diovane Monteiro Status: Em andamento

4. Requisitos no compreendidos adequadamente Probabilidade: 25% Impacto:Crtico

Descrio:Nem todos os requisitos foram adequadamente capturados durante o processo de elicitao, assim como na adoo da metodologia Scrum. Estratgia de reduo: Reunies constantes com os integrantes e o ProductOwner, com a finalidade de sanar dvidas relacionadas ao requisitos, mapeamento dos mesmo e criao do backlog. Plano de Contingncia: Analisar os documentos gerados pelas reunies e reaver os conceitos relacionados aos requisitos do sistema. Responsvel: Diovane Monteiro

16

5. Afastamento de membro relativo ao projeto Probabilidade: 15% Impacto: Crtico

Descrio: Os integrantes do projeto so, em sua maioria, assduos e compromissados com o trabalho, porm por motivos de sade e/ou locomoo, a ausncia em determinadas fases do projeto so plausveis. Estratgia de reduo: Distribuio das atividades do membro em questo para os demais da equipe, assim como mudanas na prioridade do escopo. Plano de Contingncia: No caso do afastamento ou abandono deste membro da equipe, todas suas tarefas devero ser redistribudas e replanejadas. Responsvel: Renan Reis

6. Disperso da equipe durante o projeto Probabilidade: 95% Impacto:Marginal

Descrio: A disperso dos membros da equipe est relacionada ao tempo disponvel para se dedicar ao projeto, assim como o tempo possvel para reunies cara a cara e afins. Estratgia de reduo: Distribuio das funes dos membros da equipe, de forma que cada papel especfico possa gerar ao final de cada tarefa o status relacionado, criando assim controle sobre o andamento das tarefas. Plano de Contingncia: Criar meios para interao assncrona entre os integrantes da equipe, amenizando assim o impacto da disperso. Responsvel: Renan Reis

17

7. Disponibilidade parcial do tempo Probabilidade: 90% Impacto:Marginal

Descrio:O tempo disponvel para dedicao do projeto parcialmente aproveitado, visto que nenhum dos integrantes possui tempo integral para dedicao ao mesmo. Estratgia de reduo: Iniciar o planejamento de atividades da forma identificada como ideal para a diviso de tempo e aproveitamento da disponibilidade de cada integrante. Plano de Contingncia: Criar meios em que a equipe possa trabalhar de forma dessincronizada e em tempo disponvel. Responsvel: Katlen Maduro Status: Risco ocorreu de fato. O Planejamento das atividades foram realizadas para alguns membros da equipe. Vrias tarefas foram afetadas por atrasos e consequentemente repassadas para outras Sprints.

8. Utilizao de tecnologias recentes Probabilidade: 45% Impacto:Marginal

Descrio: Parte dos membros no possua experincia nas ferramentas e tecnologias utilizadas Estratgia de reduo: Induzir os membros com menos experincia ao aprendizado das tecnologias com outros membros que j possuem mais experincia. Plano de Contingncia: Criar um programa de treinamento para a tecnologia solicitada. Responsvel: Marcos Felipe Status: Risco ocorreu de fato. Alguns integrantes da equipe necessitaram de um treinamento prvio nas tecnologias empregadas.
18

4. Planejamento Temporal

No Planejamento Temporal so definidas as datas de execuo das tarefas assim como, os responsveis por cada uma delas atravs 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 so apresentados o Modelo de Processo escolhido e as suas atividades e tarefas que foram escolhidas para serem apresentadas nesta seo. Com base nos clculos descritos na seo 2 presente no item 2.3 (Resultados), o esforo estimado para a realizao do projeto de 192 dias trabalhados, demonstrados na tabela abaixo, divididos por fases que vo desde o planejamento at os testes. Fase Planejamento Anlise requisitos Gerao de Cdigo Testes Projeto 20% 20% 20% 40% Clculo 192X20% 192X20% 192X20% 192X40% TOTAL Dias Trabalhados 38,4 38,4 38,4 76,8 192

19

4.2 Diagrama de Gantt

O diagrama de Gantt um grfico usado para ilustrar o avano das diferentes etapas de um projeto. Os intervalos de tempo representando o incio e fim de cada fase aparecem como barras coloridas sobre o eixo horizontal do grfico. [2]

Na seo 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 so exibidos o diagrama e as tarefas, respectivamente.

20

5. Organizao do Pessoal

A organizao pessoal se baseou em encontros com a equipe, alm de comunicao via e-mail, gtalk, dentre outros meios possveis, 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 reunio diria, a reviso das metas a cada final da sprint, analisando as tarefas e atrasos em retrospectiva para aprimoramento das metas. Os papis descritos so: Scrum Master, Developer1, Developer2 e Tester, sendo o ProductOwner o Prof Dr. Arilo Dias. A disposio dos integrantes, relacionados a seus respectivos papis, so modificados a cada Sprint. Scrum Master O Scrum Master caracteriza-se como o responsvel pelo incentivo equipe, com a tarefa de remover possveis impedimentos que influenciem na parte operacional, alm de ser o responsvel pelo registro de determinadas atividades da Sprint. Vale ressaltar que o Scrum Master no o lder da equipe, somenete exerce a funo de apoio. Desenvolvedores Desenvolvedores so os membros com todas as habilidades necessrias para transformar os requisitos do ProductOwner em um pedao potencialmente distribuvel do produto ao final da Sprint. ProductOwner O ProductOwner a nica pessoa responsvel pelo gerenciamento do Backlog do Produto e por garantir o valor do trabalho realizado pelo Time Scrum, garantindo que seja visvel para todos da equipe.
21

Tester ou Testador O Tester faz a integrao com a equipe de anlise e desenvolvimento procurando entender as regras de negcio, arquitetura e funcionamento das atividades no sistema para validar o sistema.

5.2 Mecanismos de comunicao

Redmine Redmine um software livre e de cdigo aberto para gerenciamento de projetos. Foi desenvolvido na linguagem Ruby utilizando framework Ruby on Rails. Redmine uma ferramenta multi-plataforma que suporta vrios bancos de dados, extenses de plugins e sistema de controle de verso. [3] Nele os documentos foram centrados para consulta da equipe por todos os envolvidos e para acompanhamento de mudanas na documentao relacionado ao projeto. E-mail e Chats Um meio importante para comunicao entre a equipe se baseou em e-mails e chats, aonde 90% da iterao entre os integrantes foi efetuada. Aplicativos (Whatsapp) Outros meios que foram utilizados para comunicao, so aplicativos para smartphones, com a criao de grupos nos mesmos.

22

5.3 Uso do Edu-blog como ferramenta de apoio [1]

A utilizao do Edu-blog como ferramenta de apoio foi de grande valia para complementao dos trabalhos aqui desenvolvidos, assim como o mesmo agrega valor aos conhecimentos que so exibidos na ferramenta.

Pelo fato da ferramenta ser multiplataforma, seu fcil entendimento em questo de navegabilidade e seu contedo 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 documentao 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

6. Precaues 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 usurio, revises a cada Sprint, juntamente com os envolvidos, so uma forma de garantir a qualidade e assegurar que o escopo vlido.

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 validao com o cliente. 6.2 Revises Tcnicas Formais As revises so realizadas na etapa de Anlise e Projeto, visando identificao de erros nas fases iniciais do projeto, onde o custo para a manuteno menor. 6.3 Produo de Documentao Para o controle de qualidade do processo de desenvolvimento, foi elaborada documentao nas etapas de Anlise, Projeto e Teste em todo o processo de execuo do projeto.

24

7.1 ANEXOS

Figura 1.1 - Diagrama lgico do sistema SIGEM

25

Figura 1.2 - Modelo EER (Estendido) do sistema SIGEM

26

Figura 1.3 Diagrama de classes do sistema SIGEM

27

Figura 1.4 - Tela visualizao de equipamentos do sistema SIGEM

28

Figura 1.5 - Tarefas extradas do redmine

29

Figura 1.6 - Diagrama de Gantt extrado do redmine

30

Referncias

[1] - Edu Blog- Informaes respeito da documentao. Disponvel em: http://gp-ufam2012.blogspot.com.br. Acesso em: 17 de mar. 2013. [2] - Redmine - Diagrama de Gantt e tarefas das Sprints. Disponvel em: http://redmine.icomp.ufam.edu.br/projects/b/issues/gantt. Acesso em: 20 de mar. 2013. [3] - Viva o Linux Informaes sobre o Redmine. Disponvel em: http://www.vivaolinux.com.br/artigo/Gerencia-de-projetos-com-Redmine/. Acesso em: 14 de mar. 2013.

31