1. 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
2. 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
3. Í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
4. 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
5. ● 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
6. ● 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
7. ● 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
8. 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
9. 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
10. 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
11. 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
12. 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
13. 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
14. 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
15. ○ 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
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. 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
Probabilidade: 80% Impacto: Catastrófico
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
17. Plano de Contingência: Investir em treinamento na metodologia solicitada e realizar
práticas no desenvolvimento do projeto.
Responsável: Augusto Arruda
Status: Finalizada
3. Prazo de entrega não ser cumprido
Probabilidade: 50% Impacto: Catastrófico
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.
Responsável: Augusto Arruda
4. Uso de novas Tecnologias
Probabilidade: 50% Impacto: Catastrófico
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
18. 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.
Responsável: Denise Sena
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
19. 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.
Responsável: Denise Sena
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
20. 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
21. 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
22. 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
23. 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
24. 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
25. 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
26. 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
27. 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:
Teste dos artefatos criados
Apresentação da Sprint 2 ao Produtc Owner
3ª Sprint
Especificação:
Reavaliação da Sprint 2
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:
Teste dos artefatos criados
Apresentação da Sprint 3 ao ProdutcOwner
27
28. 4ª Sprint
Especificação:
Reavaliação da Sprint 3
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:
Teste dos artefatos criados
Apresentação da Sprint 4 ao ProdutcOwner
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