Sistema de Gerenciamento de Projetos de Pesquisa e Desenvolvimento

UNIVERSIDADE FEDERAL DO AMAZONAS
INSTITUTO DE COMPUTAÇÃO

PLANO DO PROJETO DE SOFTWARE
PARA PRODUTOS DA LACERTAE SW

Augusto Rozendo Ribeiro de Arruda – 20901910
Denise Maciel Sena - 21000963
Diana Santos Lemos - 21001000

MANAUS
2013

UNIVERSIDADE FEDERAL DO AMAZONAS
INSTITUTO DE COMPUTAÇÃO

Augusto Rozendo Ribeiro de Arruda – 20901910
Denise Maciel Sena - 21000963
Diana Santos Lemos - 21001000

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 - GERENCIA DE
PROJETOS, ministrada pelo
Prof.Rogerio Patricio Chagas do
Nascimento.

MANAUS
2013

Índice

1. INTRODUÇÃO ............................................................................................................................................ 4
1.1 ÂMBITO DO PROJETO ......................................................................................................................... 4
1.2 FUNÇÕES PRINCIPAIS DO PRODUTO DE SOFTWARE .......................................................................... 4
1.3 REQUISITOS COMPORTAMENTAIS OU DE PERFORMANCE .................................................................. 5
1.4 GESTÃO E RESTRIÇÕES TÉCNICAS.................................................................................................... 6
2. ESTIMATIVAS DO PROJETO.................................................................................................................. 8
2.1 DADOS HISTÓRICOS UTILIZADOS PARA AS ESTIMATIVAS ......................................................................... 8
2.2 TÉCNICAS DE ESTIMAÇÃO E RESULTADOS............................................................................................... 8
2.2.1 TÉCNICA DE ESTIMATIVAS..................................................................................................................... 8
2.3 RESULTADOS ........................................................................................................................................... 9
2.4 RECURSOS DO PROJETO ....................................................................................................................... 11
2.4.1 RECURSOS HUMANOS ........................................................................................................................ 11
2.4.2 RECURSOS DE SOFTWARE ................................................................................................................. 11
2.4.3 RECURSOS DE HARDWARE ................................................................................................................ 12
3.0 ANÁLISE E GESTÃO DE RISCOS ..................................................................................................... 13
3.1 RISCOS DO PROJETO ............................................................................................................................. 13
3.2 AVALIAÇÃO GLOBAL DOS RISCOS .......................................................................................................... 14
3.3 TABELA DE RISCOS ................................................................................................................................ 15
3.4 REDUÇÃO E GESTÃO DO RISCO ............................................................................................................ 16
4.0 PLANEJAMENTO TEMPORAL ........................................................................................................... 20
4.1 CONJUNTO DE TAREFAS DO PROJETO .................................................................................................. 20
4.2 DIAGRAMA DE GANTT ............................................................................................................................ 21
4.3 COMPARATIVO DE PLANEJAMENTO........................................................................................................ 21
5.0 ORGANIZAÇÃO DO PESSOAL .......................................................................................................... 22
5.1 ESTRUTURA DA EQUIPE ......................................................................................................................... 22
5.2 MECANISMOS DE COMUNICAÇÃO ........................................................................................................... 23
5.3 USO DO EDU-BLOG COMO FERRAMENTA DE APOIO .............................................................................. 24
6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO
PRODUTO DE SW ........................................................................................................................................ 26
ANEXO 1 – DIAGRAMA DE CLASSES A................................................................................................ 29
ANEXO 2 - DIAGRAMA DE CLASSES B................................................................................................. 30
ANEXO 3 – DIAGRAMA DE GANNT ........................................................................................................ 31

1. Introdução

1.1 Âmbito do Projeto

O Sistema de Gerenciamento de Projetos de Pesquisa e Desenvolvimento tem
por objetivo auxiliar a secretaria e os professores autorizadosque atuarão como
coordenadoresno gerenciamento de projetos atrelados ao Instituto de Computação da
Universidade Federal do Amazonas. O Sistema permite ao usuário administrar as
despesas pertencentes às rubricas de um determinado projeto, realizando ainda um
serviço de upload de documentos importantes para consultas futuras, como notas
fiscais, documentos de propostas de projeto, editais, etc, além de ter a funcionalidade
de gerar relatórios das movimentações realizadas no projeto.

1.2 Funções principais do produto de software

As principais funcionalidades do Sistema de Controle de Projetos de Pesquisa e
Desenvolvimento são:
● Cadastrar Unidade de Fomento
● Editar Unidade de Fomento
● Excluir Unidade de Fomento
● Pesquisar Unidade de Fomento
● Cadastrar Projetos
● Editar Projetos
● Excluir Projetos
● Pesquisar Projetos
● Cadastrar Rubricas
● Editar Rubricas
● Excluir Rubricas
● Pesquisar Rubricas
4

● Consulta de saldo por Rubrica
● Registrar Datas (Início, Término, Prestação de Contas).
● Solicitar/ Registrar Gastos
● Gerar Relatórios Detalhados/Simplificados de Rubricas
● Movimentar Saldo de Rubricas

O sistema deve permitir as seguintes funcionalidades para os usuários do
sistema:

Secretaria
● Gerenciamento das Unidades de Fomento
● Gerenciamento dos Projetos
● Gerenciamento de Rubricas
● Conceder acesso a Coordenadores

Coordenador
● Consultar as rubricas do projeto
● Manipular dados do projeto quando autorizado

1.3 Requisitos comportamentais ou de performance

● Disponibilidade:
○ Rodará durante 24hs por dia, sete dias por semana.
● Segurança:
○ O sistema não deve permitir acesso por usuários não autorizados.
○ Senhas devidamente criptografadas e especificas por usuários.
● Portabilidade:
○ O sistema deve ser executado em plataformas Linux e Windows, XP ou
superior.
○ O sistema deve ser compatível com os browsers Mozilla Firefox e Google
Chrome.

5

● Eficiência:
○ Em condições normais, o sistema deve responder a qualquer requisição
no máximo em 3 segundos.
○ Em condições de pico de uso, o sistema deve responder a qualquer
requisição no máximo em 6 segundos.
● Integridade:
○ O sistema deverá exibir os dados de um projeto somente para seus
respectivos coordenadores e secretaria.
○ Um coordenador só poderá manipular um projeto relacionado a ele.
○ Somente a secretaria e o coordenador mediante autorização poderão
manipular dados de projetos.
○ Somente a secretaria poderá gerenciar projetos de todos os
coordenadores.
● Usabilidade:
○ Interface simples: o sistema exibe uma barra de menu contendo todas as
funcionalidades disponíveis ao usuário.
○ Interface amigável e de fácil manuseio pelo usuário, processos são bem
descritos.

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:

● O produto deve ser implementado como uma aplicação web e portável a várias
plataformas;
● O produto deve ser implementado na linguagem de programação PHP, HTML
utilizando o Framework Joomla;
● O produto deve utilizar Banco de Dados Mysql;
● Datas de entrega inflexíveis, pois o processo de desenvolvimento ágil (SCRUM)
exige uma apresentação em datas previamente estipuladas;
6

● Falta de experiência prática com as ferramentas e métodos utilizados para o
desenvolvimento.
● Falta de capacitação técnica da equipe, sendo necessário um treinamento
específico para alguns componentes da equipe com ferramentas que serão
utilizadas;

7

2. ESTIMATIVAS DO PROJETO

Estimativa é avisão de um resultado que não podemos dizer que é correto e nem
exato, é, contudo, um resultado aproximado. As estimativas são importantes, pois
proporcionarão ao gestor uma maior percepção da duração totaldo projeto. Na
estimativa serão efetuados os cálculos necessários para determinar o tempo de cada
fase do projeto, usando a metodologia SCRUM.

2.1 Dados históricos utilizados para as estimativas

Dentre muitos projetos desenvolvidos pela equipe, este é o pioneiro, no qualo
cálculo para estimativa da duração total do projeto se apresenta em dias. Destaca-se
como dado relevante a equipe ser composta por acadêmicos inexperientes na área de
Gestão de Projetos.

2.2 Técnicas de estimação e resultados

Para encontrar o tempo, será necessário aplicar uma técnica de estimativa.
Neste caso iremos utilizar a métrica adotada pela Lacertae Software, Lorenz & Kidd
(orientada a classes).

2.2.1 Técnica de estimativas

Para o projeto de Gerenciamento de Projetos de Pesquisa e Desenvolvimento foi
utilizado à técnica de estimativa Lorenz & Kidd definida pela Lacertae Software. Trata-
sede uma métrica orientada a classes, que consiste em:

1 Determinar a quantidade de classes chaves do projeto.

8

2 Encontrar o número de classes de suporte, identificando o tipo de interface do
produto e usando o multiplicador correspondente para calcular o número
declasses de suporte.
3 Multiplicar a quantidade de Classes-chave pelo valor Multiplicador, obtendo o
número de Classes de suporte;
4 Cálculo da quantidade total de classes (Classes-chave + Classes de suporte);
5 Multiplicar o total de classes pelo número médio de unidades de trabalho (dias-
pessoa);
6 Determinar a quantidade de esforço estimada;
7 Cálculo do tempo previsto para a realização do projeto.

Abaixo, a tabela apresenta os fatores de multiplicação utilizados para encontrar a
quantidade de classes de suporte:

INTERFACE VALOR MULTIPLICADOR

Interface Valor multiplicador Não gráfica 2

Baseada em texto 2,25

GUI 2,5

GUI Complexa 3

2.3 Resultados

Com a aplicação da métrica de Lorenz & Kidd definida pela Lacertae Software,
os seguintes resultados foram obtidos:

9

1 O número de classes chaves do projeto foram escolhidas através dos diagramas
de classes apresentados nos anexos 1 e 2.
2 Como o projeto é um sistema para ambiente WEB, utilizará interface GUI
complexa, dessa forma o fator multiplicador serão 3.
3 O número de classes de suporte pode ser encontrado a partir do número de
classes chave x multiplicador, dessa forma, 4 x 3 = 12 classes de suporte.
4 O total de classes do projeto será número de classes chave + número de classes
de suporte, onde 4 + 12 = 16 classes.
5 Pelo fato da equipe não possuir experiência em projetos deste gênero e a
quantidade de classes serem baixas, foi escolhido o número mínimo de unidades
de trabalho por pessoa, 15 dias-pessoa.
6 O cálculo do esforço estimado ficou da seguinte forma: 16 classes x 15 dias-
pessoa, onde 240 dias de trabalho.
7 Considerando 3 pessoas envolvidas no projeto e 22 dias úteis de trabalho por
mês => 240/3 = 80 dias, aproximadamente 3,3 meses.

Considerando que os dias de trabalho totais são 240 dias, esses dias agora são
distribuídos de acordo com as seguintes percentagens de distribuição dos componentes
essenciais no projeto, sugeridas pela Lacertae Software:

1) Planejamento: 2-3%
2) Análise e Projeto: 20%
3) Geração de Código: 40%
4) Testes: 37-38%

Os valores calculados são:

1) Planejamento: 420 * 3% = 7,2 dias de trabalho
2) Análise e Projeto: 420 * 20% = 48 dias de trabalho
3) Geração de código: 420 * 40% = 96 dias de trabalho
4) Testes: 420 * 37% = 88,8 dias de trabalho

10

2.4 Recursos do projeto

Os recursos que serão utilizados no desenvolvimento do projeto serão descritos
abaixo de acordo com a metodologia, tecnologias e ambiente disponível.

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, sendo três de desenvolvimento/teste e um de gerenciamento, que
exercerão diferentespapéis necessários à execução, conforme descrito abaixo:

Sprint 1 Sprint 2
Período: 07/01 à 23/01 Período: 28/01 à 20/02
Scrum Master: Augusto Arruda Scrum Master: Darlison Osório
Developer 1: Darlison Osório Developer 1: Denise Sena
Developer 2: Diana Lemos Developer 2: Augusto Arruda
Tester: Denise Sena Tester: Diana Lemos

Sprint 3 Sprint 4
Período: 25/02 à 13/03 Período: 18/03 à 03/04
Scrum Master: Denise Sena Scrum Master: Diana Lemos
Developer 1: Diana Lemos Developer 1: Augusto Arruda
Developer 2: Darlison Osório Developer 2: Denise Sena
Tester: Augusto Arruda Tester: Darlison

Obs.. O testador não deve testar o seu próprio programa, mas ele deve testar o
de outro programador.

2.4.2 Recursos de Software

O projeto irá usufruir dos seguintes softwares para composição do produto
desoftware, além do projeto de gerência de produção:

11

Xampp – 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.

NetBeans 7.2.1 e Notepad ++ v6.2.2 – 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.

Joomla 2.5 – É CMS para gerenciamento de conteúdo no qual será gerado um
componente que gerenciará os projetos de Pesquisa e Desenvolvimento no site do
Instituto de Computação - IComp.

OpenOffice e Microsoft Word – Editores de texto usados na documentação, relatórios
e documentos afins.

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 três notebooks.

12

3.0 ANÁLISE E GESTÃO DE RISCOS

Esta análise consiste em uma série de passos que permitem compreender e
gerir os riscos incertos 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 que precisam ser monitorados
durante o projeto são:

Risco Projeto Técnico Negócio Comum Especial

Equipamento indisponível x

Requisitos Incompletos e x x x
Regras de Negócios não
definidas

Requisitos em constante x
mudanças

Uso de metodologias x x
especiais

Falta experiência com as x
tecnologias específicas e a
equipe não obter
treinamento adequado

13

Falha na integração com os x x
demais sistemas

Rotatividade da Equipe x

Membro se ausentar do x x
projeto

3.2 Avaliação global dos riscos

● O Gestor de Software dá suporte ao projeto?
○ Sim, pois o gestor é um dos participantes direto que possui muito
conhecimento adquirido sobre o projeto.
● Os Clientes estão entusiasmados com o projeto e o produto?
○ O cliente e usuários estão entusiasmados para adquirir o produto final e
contribuem para o desenvolvimento do projeto.
● Os Engenheiros de Software compreenderam bem os requisitos?
○ Sim, todos sabem o que o sistema deve conter através dos requisitos
descritos inicialmente, porém a ocorrência de mudanças no decorrer de
cada interação será constante.
● Os Clientes estiveram envolvidos na definição dos requisitos?
○ Sim, houve a elicitação dos requisitos com o cliente por meio de
umareunião inicial e foram esclarecidos serviços que o sistema deve
realizar
● O âmbito do projeto é estável?
○ Sim, o âmbito do nosso projeto não foi alterado.
● Os engenheiros de Software têm as competências requeridas?
○ Os engenheiros de Software não possuem capacidade e competência
necessária para a elaboração deste projeto, no entanto, deverão ser
treinados para apresentar melhores resultados.
● Os requisitos do projeto são estáveis?

14

○ Não, os requisitos não são estáveis, pois haverá mudançasno decorrer do
projeto.
● A equipe de desenvolvimento tem experiência na tecnologia a implementar?
○ Não, a equipe não possui conhecimentos nas tecnologias especificadas.
● É adequado o número de pessoas da equipe de trabalho?
○ Não, é um trabalho extenso para um número reduzido de pessoas o que
levará a um esforço complementar de cada um.

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

Requisitos em constantes
1 90% Catastrófico
mudanças.
Falta de Experiência na
2 80% Catastrófico
Metodologia de Desenvolvimento
3 Prazo de entrega não sercumprido. 50% Catastrófico

4 Uso de novas tecnologias. 50% Catastrófico

Membros trabalhando em partes do
5 80% Crítico
tempo.
Membro se ausentar ou abandonar
6 60% Crítico
o projeto.
Dúvidas sobre a implementação de
7 30% Marginal
requisitos do sistema.

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. Requisitos e constantes mudanças

Probabilidade: 90% Impacto: Catastrófico

Descrição:Mudanças constantes no escopo inicial do projeto podem atrasar o projeto
devido ao replanejamento das atividades necessárias para adequar o projeto aos
novos requisitos

Estratégia de redução: Realizar reuniões periódicas com o cliente para esclarecer
requisitos e regras de negócio conforme o projeto é desenvolvido .

Plano de Contingência: Adequar e replanejar atividades para atender e acomodar
as mudanças nos requisitos atualizando diagrama de classes gráfico de Gannt e etc.

Responsável: Augusto Arruda

Status: Em andamento

2. Falta de Experiência na Metodologia de Desenvolvimento


Descrição:Equipe não possui experiência em desenvolvimento de sistema com a
metodologia SCRUM.

Estratégia de redução: Realizar estudos sobre a metodologia SCRUM que foi
estipulada a ser adotada pela equipe.

16

Plano de Contingência: Investir em treinamento na metodologia solicitada e realizar
práticas no desenvolvimento do projeto.


Status: Finalizada

3. Prazo de entrega não ser cumprido


Descrição: Prazo estimado do projeto (3 meses e 3 semanas, quase 4 meses) é
maior que o prazo disponível para desenvolvimento do projeto (3 meses).

Estratégia de redução: Realizar acompanhamento e controle do andamento do
projeto com ajuda de ferramentas e priorizar atividades que sejam mais importantes
para o atendimento dos requisitos do usuário.

Plano de Contingência: No caso de o prazo disponível não ser suficiente, o software
deverá ser entregue com as funcionalidades mais importantes de Gerenciamento de
Projetos de Pesquisa e Desenvolvimento.


4. Uso de novas Tecnologias


Descrição: Todos os membros não possuem experiência na tecnologia especificada
para desenvolver o projeto.

Estratégia de redução: Promover plano de estudos introdutórios da tecnologia.
especificada para todos da equipe

17

Plano de Contingência: Investir em treinamento na tecnologia solicitada e criar uma
atividade no cronograma para estudos da tecnologia e ferramentas.

Responsável: Denise Sena

Status: Risco ocorreu de fato. O treinamento foi um aprendizado força bruta das
ferramentas especificadas e houve pouco tempo para a equipe adquirir conhecimento
necessário para o desenvolvimento do projeto.

5. Membro trabalhando em partes do tempo

Probabilidade: 80% Impacto: Crítico

Descrição: Alguns membros da equipe não possuem tempo integral para dedicação
no desenvolvimento do projeto.

Estratégia de redução: Planejar atividades de forma que os integrantes possam
completá-las no prazo estimado de acordo sua disponibilidade.

Plano de Contingência: Incentivar o empenho da equipe em finais de semana,
feriados e folgas.


Status: Risco ocorreu de fato. O Planejamento das atividades foram realizadas para
alguns membros da equipe.

6. Membro se ausentar ou abandonar o projeto.

Probabilidade: 60% Impacto: Crítico

Descrição: Um dos integrantes da equipe está com dificuldades para estar reunido

18

com a equipe no desenvolvimento do projeto, há o risco deste se ausentar durante a
execução do projeto ou até mesmo abandoná-lo.

Estratégia de redução: Distribuição das atividades do membro em questão para os
demais da equipe e treinamento de possíveis substitutos e sua função.

Plano de Contingência: No caso do afastamento ou abandono deste membro da
equipe, todas suas tarefas deverão ser redistribuídas e replanejadas em todo escopo
do projeto a ser concluído.


Status: Risco ocorreu de fato. Atividades do membro em questão foram
redistribuídas para os demais da equipe.

7. Duvidas sobre a implementação dos requisitos do sistema

Probabilidade: 30% Impacto: Marginal

Descrição: Devido à equipe adotar o processo SCRUM que é uma metodologia
ágil,a cada nova interação há uma série de dúvidas quanto ao que alguns
requisitosrepresentam em uma determinada parte no sistema.

Estratégia de redução: Elaborar um relatório sobre os requisitos apresentados no
documento de especificação de requisitos, abordando o que ele representará em
cada parte que o mesmo será utilizado no sistema.

Plano de Contingência: Realizar a consulta no Relatório elaborado sobre os
requisitos para a melhor compreensão do requisito na hora da implementação do
sistema e maior interação com o usuários/clientes

Responsável: Diana Lemos

19

4.0 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
elaborado pelo Scrum Master da primeira sprint de comum acordo com os demais
componentes da equipe.

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 secçã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 240 dias trabalhados, abaixo está
sendo exibido o plano temporal das fases do projeto.

Fase Projeto Cálculo Dias Trabalhados

Planejamento 3% 420X3% 7,2

Análise requisitos 20% 420X20% 48

Geração de Código 40% 420X40% 96

Testes 37% 420X37% 88,8

TOTAL 240

20

4.2 Diagrama de Gantt

Com o uso do diagrama de Gantt, se obtém maior detalhamento das etapas de
desenvolvimento do sistema, exibindo o tempo programado para execução de cada
uma delas além de expor o desenrolar de cada uma das atividades. Para tanto o usou-
se a ferramenta MsProject para a criação do Diagrama de Gantt (anexo 3).

4.3 Comparativo de planejamento

Baseado no que foi descrito pelo tópico 4.1 é notório que os cálculos elaborados
para desenvolvimento dosartefatos não se aplicam a realidade do projeto em questão
no que tange ao tempo estimado de 240 dias. O projeto Controle de Projetos de
Pesquisa e Desenvolvimento, por ser tratar de um projeto acadêmico teve suas datas
previamente definidas pelo orientador do projeto impossibilitando ultrapassar o prazo
estipulado do semestre, mesmo que o projeto não seja concluído.

21

5.0 ORGANIZAÇÃO DO PESSOAL

Conforme a estimativa elaborada do esforço a ser empregado por cada membro
da equipe para a criação do projeto e, observando os papéis definidos à organização
pessoal, o grupo se organiza usando comunicações das mais variadas que vai do
compartilhamento de documentos, usando ferramentas online, chats, e-mail,telefones
entre outros para a integração com o cliente do projeto.

5.1 Estrutura da equipe

A equipe é formada por 4 integrantese o cliente do sistema. Sendo todos
relacionados com atividades que devem ser executadas para a implementação do
software usando modelo de desenvolvimento ÁGIL – que prima pelo planejamento da
versão para entrega sendo mudadas as funções dos membros a cada interação, ou
seja, a cada nova Sprint.
O modelo Ágil exigirá reunião diária, a revisão das metas a cada final da sprint,
analisando as tarefas e os atrasos em retrospectiva para melhoramento das metas. Os
papéis descritos são: Scrum Master, Developer 1, Developer 2 eTester, sendo o
Product Owner o Prof Dr. Arilo Dias.

ScrumMaster
O ScrumMaster é responsável por garantir que o Time Scrum esteja aderindo
aos valores do Scrum, às práticas e às regras, levando-o a ser mais produtivo e a
desenvolver produtos de maior qualidade.

Desenvolvedores
Desenvolvedores são os membros com todas as habilidades necessárias para
transformar os requisitos do Product Owner em uma parte do artefato entregáveldo
produto ao final de cada Sprint.

22

Product Owner
O Product Owner é 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.

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

Time Scrum
Time Srum é onde os desenvolvedores transformam o Backlog do Produto em
incrementos de funcionalidades potencialmente entregáveis em cada Sprint e são
interdisciplinares: membros do Time devem possuir todo o conhecimento necessário
para criar um incremento no trabalho, realizados sempre ao iniciar uma nova sprint.

Sprint
A Sprint é uma iteração, com duração fixa, na qual tanto a composição do time
quanto as metas de qualidade devem permanecer constantes durante a Sprint. As
Sprints contêm e consistem na reunião de Planejamento de Sprint com todos os
envolvidos e é onde o trabalho de desenvolvimento é mais executado.

Product Backlog
O Procut Backlog são os requisitos do produto que o Time está desenvolvendo e
estão listados no Backlog do Produto. O Product Owner é o responsável pelo Backlog.
Neste houve uma interação de todos os envolvidos para terem ciência sobre todo o
escopo do projeto.

Redmine

23

Redmine é um software livre, gerenciador de projetos baseados na web e
ferramenta de gerenciamento de bugs. Ele contém calendário e gráficos de Gantt para
ajudar na representação visual dos projetos e seus deadlines (prazos de entrega). 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
A comunicação da equipe se deu da seguinte forma: houve algumas reuniões
presenciais e, em frequência bem superior, houve as reuniões virtuais operadas através
dos e-mails e chats pessoais de cada integrante da equipe, as quais ocorreram
acompanhando as mudanças e evoluções do projeto.

Telefone
Vale ressaltar que a comunicação telefônica foirealizada para obter
esclarecimentos e muitas vezes tirar algumas dúvidas sobre mudanças ou para saber o
andamento do projeto.

5.3 Uso do Edu-blog como ferramenta de apoio

O Edu-Blog é uma excelente via para o conhecimento, pois não se limita a
textos, mastambém a programas.
É um espaço onde acadêmicos apreciadores da área e o público em geral
podem comentar ou criticar as postagens feitascom baseem pesquisas científicas e de
cotidiano, trabalhando o pesquisar, o entender e o escrever. Assim, as formas mais
eficientes de comunicação, produção de textos e conhecimento de tecnologias,
elencando o professor que além de orientador passa a ser também observador dos
trabalhos.
Tais fatos nos leva a crer que os Blogs Educacionais, em especial o Edu-blog é
sem dúvida,uma ferramenta de conhecimento que provem da facilidade de
comunicação dada pela praticidade e rapidez da interação da linguagem representativa
que aparece no meio digital, ou seja, é usar a tecnologia para ensinar por ela própria.

24

Mas, toda e qualquer ideia, pode sim ser melhorada e a contribuição de nossa equipe
para melhoria, está no fato de escrever sobre temas onde existe uma gama enorme de
informações e fazer isso com uma frequência, ainda que sem um retorno. Por mais
simples que seja essa tarefa, acaba desmotivando o autor acadêmico do blog, pela
certeza ou não de que sua exposição está satisfazendo ou não o público alvo, para
tanto a sugestão é usar outros acadêmicos de outros períodos ou professores da área
para contribuírem com sugestõesvisitando os blogs e gerando críticas sobre eles, com a
moderação feita pelo professor da disciplina.

25

6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE
DO PRODUTO DE SW

Atividades de teste serão aplicadas ao final do desenvolvimento de cada
funcionalidade para assegurar que são atendidas conforme foram especificadas. Será
feito acompanhamento contínuo do trabalho desenvolvido por todos os participantes do
projeto, aplicar-se-ão revisões técnicas, análise e controle contínuo de riscos, bem
comoserão geradas documentações do projeto e produto.

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.

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.

Produção de Documentação
Para o controle de qualidade do processo de desenvolvimento, foi elaborada
documentação nas etapas de Especificação, Codificação e Teste em todo o processo
de execução do projeto. Assim descritas:

1ª Sprint
Especificação:
Instalação de sistemas para desenvolvimento XAMP, Joomla
Configuração e importação da base de dados ICOMP
Modelagem das tabelas de Banco de Dados da base ICOMP
Planning poker
Codificação:
Crud coordenador
Crud Fomento

26

Crud despesas
Teste:
Criação de testes das histórias
Teste dos artefatos criados
Apresentação da Sprint 1 ao ProdutcOwner

2ª Sprint
Especificação:
Reavaliação da Sprint 1
Ajustes do ProdutcBacklog para sprint 2
Codificação:
Crud de Projetos
Crud de Rubricas
Consulta Coordenadores
Crud de Gastos
Teste:
Apresentação da Sprint 2 ao Produtc Owner

3ª Sprint
Especificação:
Ajustes do Produtc Backlog para sprint 3
Codificação:
Crud de Rubricas especificas do projeto
Relatório dos Cruds de Rubricas e Fomento
Ajustes de regras de négocio
Teste:

27

4ª Sprint
Especificação:
Ajustes do ProdutcBacklog para sprint 4
Codificação:
Crud de criação de Datas
Relatório dos Cruds de Despesas e Rubricas de despesas
Relatório de datas agendadas
Ajustes das regras de negócio
Teste:
Conclusão do Projeto e Entrega

CRUD: Acrônimo de Create, Read, Update e Delete em língua Inglesa, para as quatro
operações básicas utilizadas em bancos de dados relacionais (RDBMS) ou em interface
para usuários para criação, consulta, atualização e destruição de dados.

28

Anexo 1 – Diagrama de Classes A

29

Anexo 2 - Diagrama de Classes B

30

Anexo 3 – Diagrama de GANNT

31

Sistema de Gerenciamento de Projetos de Pesquisa e Desenvolvimento

Recomendados

Recomendados

Más contenido relacionado

Similar a Sistema de Gerenciamento de Projetos de Pesquisa e Desenvolvimento

Similar a Sistema de Gerenciamento de Projetos de Pesquisa e Desenvolvimento (20)

Sistema de Gerenciamento de Projetos de Pesquisa e Desenvolvimento