Trabalho final(25 03 2013)

UNIVERSIDADE FEDERAL DO AMAZONASINSTITUTO DE COMPUTAÇÃO

PLANO DO PROJETO DE SOFTWAREPARA PRODUTOS DA LACERTAE SW

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

MANAUS2013

UNIVERSIDADE FEDERAL DO AMAZONASINSTITUTO DE COMPUTAÇÃO

Augusto Rozendo Ribeiro de Arruda – 20901910Denise Maciel Sena - 21000963Diana 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.

MANAUS2013

Índice

1. INTRODUÇÃO..............................................................................................................................................4

1.1 ÂMBITO DO PROJETO............................................................................................................................41.2 FUNÇÕES PRINCIPAIS DO PRODUTO DE SOFTWARE...............................................................................41.3 REQUISITOS COMPORTAMENTAIS OU DE PERFORMANCE......................................................................51.4 GESTÃO E RESTRIÇÕES TÉCNICAS........................................................................................................6

2. ESTIMATIVAS DO PROJETO...................................................................................................................8

2.1 DADOS HISTÓRICOS UTILIZADOS PARA AS ESTIMATIVAS............................................................................82.2 TÉCNICAS DE ESTIMAÇÃO E RESULTADOS..................................................................................................82.2.1 TÉCNICA DE ESTIMATIVAS.......................................................................................................................82.3 RESULTADOS...............................................................................................................................................92.4 RECURSOS DO PROJETO.............................................................................................................................112.4.1 RECURSOS HUMANOS............................................................................................................................112.4.2 RECURSOS DE SOFTWARE......................................................................................................................112.4.3 RECURSOS DE HARDWARE.....................................................................................................................12

3.0 ANÁLISE E GESTÃO DE RISCOS.........................................................................................................13

3.1 RISCOS DO PROJETO..................................................................................................................................133.2 AVALIAÇÃO GLOBAL DOS RISCOS.............................................................................................................143.3 TABELA DE RISCOS....................................................................................................................................153.4 REDUÇÃO E GESTÃO DO RISCO................................................................................................................16

4.0 PLANEJAMENTO TEMPORAL............................................................................................................20

4.1 CONJUNTO DE TAREFAS DO PROJETO.......................................................................................................204.2 DIAGRAMA DE GANTT..............................................................................................................................214.3 COMPARATIVO DE PLANEJAMENTO...........................................................................................................21

5.0 ORGANIZAÇÃO DO PESSOAL.............................................................................................................22

5.1 ESTRUTURA DA EQUIPE.............................................................................................................................225.2 MECANISMOS DE COMUNICAÇÃO..............................................................................................................235.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 autorizados que atuarão como

coordenadores no 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

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.

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;

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;

8

2. ESTIMATIVAS DO PROJETO

Estimativa é a visã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 total do 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 qual o

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-

se de uma métrica orientada a classes, que consiste em:

1 Determinar a quantidade de classes chaves do projeto.

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 de

classes 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:

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

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 diferentes papéis necessários à execução, conforme descrito abaixo:

Sprint 1Período: 07/01 à 23/01Scrum Master: Augusto ArrudaDeveloper 1: Darlison OsórioDeveloper 2: Diana LemosTester: Denise Sena

Sprint 2Período: 28/01 à 20/02Scrum Master: Darlison OsórioDeveloper 1: Denise SenaDeveloper 2: Augusto ArrudaTester: Diana Lemos

Sprint 3Período: 25/02 à 13/03Scrum Master: Denise SenaDeveloper 1: Diana LemosDeveloper 2: Darlison OsórioTester: Augusto Arruda

Sprint 4Período: 18/03 à 03/04Scrum Master: Diana LemosDeveloper 1: Augusto ArrudaDeveloper 2: Denise SenaTester: 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 de

software, além do projeto de gerência de produção:

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.

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

Regras de Negócios não

definidas

x x x

Requisitos em constante

mudanças

x

Uso de metodologias

especiais

x x

Falta experiência com as

tecnologias específicas e a

equipe não obter

treinamento adequado

x

14

Falha na integração com os

demais sistemas

x x

Rotatividade da Equipe x

Membro se ausentar do

projeto

x x

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 uma

reuniã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?

15

○ Não, os requisitos não são estáveis, pois haverá mudanças no 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

1Requisitos em constantes mudanças.

90% Catastrófico

2Falta de Experiência na Metodologia de Desenvolvimento

80% Catastrófico

3 Prazo de entrega não ser cumprido. 50% Catastrófico

4 Uso de novas tecnologias. 50% Catastrófico

5Membros trabalhando em partes do tempo.

80% Crítico

6Membro se ausentar ou abandonar o projeto.

60% Crítico

7Dúvidas sobre a implementação de requisitos do sistema.

30% Marginal

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


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.

17

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

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.


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

com a equipe no desenvolvimento do projeto, há o risco deste se ausentar durante a

19

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 requisitos

representam 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

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

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 dos artefatos 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.

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 integrantes e 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 e Tester, 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ável do

produto ao final de cada Sprint.

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

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 foi realizada 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, mas também a programas.

É um espaço onde acadêmicos apreciadores da área e o público em geral

podem comentar ou criticar as postagens feitas com base em 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.

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ões visitando os blogs e gerando críticas sobre eles, com

a moderação feita pelo professor da disciplina.

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

como serã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

27

Crud despesas

Teste:

Criação de testes das histórias

Teste dos artefatos criados

Apresentação da Sprint 1 ao Produtc Owner

2ª Sprint

Especificação:

Reavaliação da Sprint 1

Ajustes do Produtc Backlog para sprint 2

Codificação:

Crud de Projetos

Crud de Rubricas

Consulta Coordenadores

Crud de Gastos

Teste:



3ª Sprint

Especificação:



Codificação:

Crud de Rubricas especificas do projeto

Relatório dos Cruds de Rubricas e Fomento

Ajustes de regras de négocio

Teste:



28

4ª Sprint

Especificação:



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.

29

Anexo 1 – Diagrama de Classes A

30

Anexo 2 - Diagrama de Classes B

31

Anexo 3 – Diagrama de GANNT

32

Trabalho final(25 03 2013)

Documents

Transcript of Trabalho final(25 03 2013)