CAMPUS BELENZINHO

Projeto Interdisciplinar Aplicado ao Curso Superior de

Tecnologia em Análise e Desenvolvimento de Sistemas

(PROINTER – ETAPA 1 - RELATÓRIO PARCIAL)

DANIELA VIRGINIO ROSA – RA 6558267844

ERIKA GONÇALVES SAMPAIO – RA 6558271364

IGOR JOSEVALDO SANTANA– RA 7981681044

LEIDY CARLA ALVES - RA 7372579587

MAGNO JOSÉ DE OLIVEIRA SOARES - RA 6946434794

SUZAN ALEXANDRA MACHADO SERRA - RA 6787405152

TUTOR: ALEXANDRE SOROKO

SÃO PAULO/SP

04/2015

1
 SUMÁRIO

Resumo...........................................................................................................................03

Introdução......................................................................................................................04

1. Requisição Formal de proposta (RFP)..................................................................05

1.1 RFP elaborada pela Desmil....................................................................................05

2. Proposta Sugerida pela Lemag..............................................................................07

2.1. Objetivo...................................................................................................................07
2.2. Da Proposta Apresentada pela DESMIL.............................................................07
2.3.Proposta de Solução da Lemag..............................................................................07

3. Organização da Lemag...........................................................................................09
3.1. Investimentos..........................................................................................................09
3.2. Prazos.......................................................................................................................09
3.3.Propriedade e Licença.............................................................................................09
3.4. Composição da equipe da Lemag..........................................................................10
3.5. Metodologias Utilizadas.........................................................................................10
3.6.Itens acordados para eventuais cobranças............................................................13
3.7. Termo de Abertura de Projeto (TAP)..................................................................15

4. Planejamento ...........................................................................................................16
4.1. Levantamento e Análise de Requisitos.................................................................16
4.2. Diagrama de caso de uso........................................................................................17
4.3. Diagrama de classe.................................................................................................18
4.4. Diagramas de sequência.........................................................................................19
4.5. Estrutura Analítica do Projeto (EAP)..................................................................21
4.6. Plano de Gerenciamento de qualidade do projeto (SCRUM)............................22

Desenvolvimento do Projeto.........................................................................................27

Conclusão........................................................................................................................28

Bibliografia.....................................................................................................................29

2
 Resumo

A Empresa Lemag venceu a licitação e foi contratada pela Instituição de Ensino

Desmil.
A Lemag foi incumbida de criar um aplicativo para uso interno na instituição. Este aplicativo
terá a seguinte funcionalidade: permitir que os alunos trabalhem de forma colaborativa para a
resolução de uma determinada tarefa e o seu acompanhamento. Voltado para o
desenvolvimento de atividades que precisam ser realizadas em grupos e com a divisão das
tarefas, de forma que seja possível o compartilhamento da versão mais recente da atividade
para todo o grupo e este, a cada nova postagem, receba uma notificação de atualização do
material construído.
Dessa forma, o aplicativo disponibiliza uma versão individual do trabalho
compartilhado e o seu respectivo histórico, bem como, a versão colaborativa, ou seja, aquela
que contempla todas as atualizações de acordo com a ordem de alteração do arquivo, por hora
e data. Armazenamento em cloud computing.

3
 Introdução

Este projeto de aplicativo mobile será para uso acadêmico discente, ou seja, para o
compartilhamento de informações entre os estudantes. Predefinição de tempo para que o
material fique armazenado, em pasta privada, de preferência que seja apenas durante a
execução do projeto. Facilidade de acesso: basta que o usuário se cadastre.
Escolha o tipo de pasta que deseja inserir seus projetos: pública ou privada e,
determine o tempo de duração do projeto. Este será o mesmo tempo em que o arquivo estará
disponível para a equipe cadastrada e vinculada ao projeto. O aplicativo disponibiliza a versão
XML, .xls e .doc do documento desenvolvido. Este pode ser executado localmente ou, através
de um navegador de internet.

4
 Relatório Parcial

1. Requisição Formal de Proposta (RFP)

1.1 RFP elaborada pela Desmil

A Instituição de Ensino Desmil foi fundada em 28 de abril de 2000. Hoje, em razão do

processo de evolução, a Desmil, por meio de uma proposta acadêmica moderna, vem
expandindo suas atividades por diversos Campus, visando à preparação de recursos humanos
altamente qualificados demandados pela política de desenvolvimento nacional.

Assim, a Desmil vem sendo reconhecida como um importante centro de produção de

conhecimento e de sua difusão a um número maior de pessoas, através das atividades de
ensino, pesquisa, extensão e pós-graduação.

• Escopo do Projeto

O solicitante sugere a criação de um aplicativo que terá a seguinte funcionalidade:

permitir que os alunos trabalhem de forma colaborativa para a resolução de uma determinada
tarefa e o seu acompanhamento. Voltado para o desenvolvimento de atividades que precisam
ser realizadas em grupos e com a divisão das tarefas, de forma que seja possível o
compartilhamento da versão mais recente da atividade para todo o grupo e este, a cada nova
postagem, receba uma notificação de atualização do material construído.

• Escopo do Produto

O aplicativo terá que disponibilizar uma versão individual do trabalho compartilhado e o

seu respectivo histórico, bem como, a versão colaborativa, ou seja, aquela que contempla
todas as atualizações de acordo com a ordem de alteração do arquivo, por hora e data.
Armazenamento deverá ser em cloud computing.

• Cronograma

5
 Definição de período para dúvidas, elaboração da solução técnica, envio da proposta etc.
O presente trabalho necessita de rapidez em sua formulação, pois a data limite para entrega é
10 de julho de 2015.

• Premissas e restrições

A necessidade da criação desse aplicativo se deu pelo fato de fazer com que os alunos
assumam responsabilidade desde o início do trabalho, tendo a oportunidade de verificar em
que grau cada membro do seu grupo está participando nas atividades, tendo também a
possibilidade dos professores interagirem com os alunos e verificar o perfil de cada um em
matéria de organização e liderança.

Há algumas restrições, é claro, referentes a tempo para implementação, custo que

acarretará pela urgência do projeto e qualidade do aplicativo.

• Responsabilidades

Esta proposta requer que as partes sejam penalizadas de acordo com um contrato
registrado e concluído juntamente com nosso jurídico. Sendo assim a necessidade de reuniões
antes mesmo do início do planejamento.

• Modelo de orçamento

A empresa contratada deverá trazer o orçamento definindo junto com o passo a passo dos
custos detalhados a cada fase do projeto.

• Critérios de Avaliação

ID Critério Descrição Métrica

1 Cumprimento de Escopo Cumprir todos os itens 100% de atendimento
descritos na “Definição de
Escopo”
2 Pontualidade Cumprir os prazos Considera-se Aceito
descritos no dentro da tolerância
“Cronograma” máxima de 10% de
desvio de prazo
3 Qualidade Cumprir os requisitos de 100% de aderência
qualidade descritos na
seção “Materiais e
localidades”
6
 • Formas de pagamento

Por ser um projeto relativamente simples, a forma de pagamento será via transferência
bancária.

• Termos e condições

O software (aplicativo) criado será de propriedade total da Desmil, sendo assim, não
deverá ser repassado a nenhuma outra empresa.

2. Proposta Sugerida pela Lemag

2.1 Objetivos

Esse documento tem como objetivo apresentar o entendimento da Lemag sobre a

demanda da DESMIL, documentada na sua RFP, assim como de propor uma solução para ela,
expondo os processos, ferramentas e diferenciais da Lemag no atendimento dessa demanda.
2.2 Da Proposta Apresentada pela DESMIL

Na RFP emitida pela DESMIL, o solicitante sugere a criação de um aplicativo que terá
a seguinte funcionalidade: permitir que os alunos trabalhem de forma colaborativa para a
resolução de uma determinada tarefa e o seu acompanhamento. Voltado para o
desenvolvimento de atividades que precisam ser realizadas em grupos e com a divisão das
tarefas, de forma que seja possível o compartilhamento da versão mais recente da atividade
para todo o grupo e este, a cada nova postagem, receba uma notificação de atualização do
material construído.
Dessa forma, o aplicativo disponibiliza uma versão individual do trabalho
compartilhado e o seu respectivo histórico, bem como, a versão colaborativa, ou seja, aquela
que contempla todas as atualizações de acordo com a ordem de alteração do arquivo, por hora
e data. Armazenamento em cloud computing.

A proposta de solução deverá contemplar aspectos técnicos, de qualidade, de processo de

desenvolvimento, de arquitetura privilegiando ambientes “free” e de argumentação científica
para as técnicas e os fundamentos utilizados. Também, a proposta deverá vir acompanhada de
um SLA (Service Level Agreement) que contemple todo o processo de desenvolvimento até a
entrega dos produtos.
2.3 Propostas de Solução da Lemag
7
 o Usuários

Os usuários do aplicativo serão um funcionário da instituição, professores e alunos

autorizados, responsáveis por administrar a manutenção de alunos e dos grupos a que
esses pertencem. O próprio aluno poderá alterar dados enviados e enviar atualizações para
outros alunos do seu grupo.
Nome Descrição Responsabilidades

Administrador do Funcionário da escola ao Incluir/alterar/remover professores,

Sistema qual é dado o poder de alunos e disciplinas;
cadastrar professores,
Consultar dados de alunos.
alunos e disciplinas

Professor Autorizado a criar e Incluir/alterar/remover alunos;

gerenciar a manutenção dos
Incluir/alterar/remover grupo;
grupos e alunos
Enviar atualizações para o grupo ou
alunos;

Aluno Alterar aluno Alterar alguns dados do próprio aluno

como: dados cadastrais, etapa atual,
corrigir ou remover as próprias
atualizações.

o Visão Geral do Aplicativo

O aplicativo proverá uma interface para manter um cadastro com as seguintes funções:
Manutenção e Consulta do Aluno, Envio de atualizações para alunos e Manutenção do
Grupo.
A operação de Manutenção se divide em Inclusão, Alteração e Exclusão.
As operações de inclusão e exclusão deverão ser realizadas exclusivamente pela
administração do aplicativo ou pelo professor. A alteração de grupo também será uma
funcionalidade de uso exclusivo do administrador ou do professor.
A aplicação terá filtros baseados em nome, ou consulta por grupo, grau de formação,
ano, curso, especialização e título.

8
 O produto desenvolvido é independente e totalmente auto contido não necessitando,
dessa forma, de outros aplicativos para o seu funcionamento.
Também será realizada uma previsão de espaço em disco utilizado e previsão de
escalabilidade para próximos trabalhos. Esta previsão constará do relatório de conclusão
do projeto.
o Funcionalidades

As principais funcionalidades do aplicativo são detalhadas nos documentos de Caso

De Uso, Tabelas e Documentos de Requisitos.

o Aplicativos Relacionados
O aplicativo é independente. Ele não interage com outros aplicativos, mas pode trocar
informações, caso necessário, a partir do banco de dados, desde que o banco seja
compartilhado entre tais aplicativos.
o Ferramentas Utilizadas

• JBuilder (implementação)
• Microsoft Visio (modelagem)
• CVS (controle de versões)
• Bugtrack do CódigoLivre (reportar bugs)
• Project (gerenciador de cronograma)
• Word (documentação)
• Oracle (armazenamento de dados)
• ICQ (compartilhamento de conhecimento)

3. Organização da Lemag
3.1 Investimentos
O projeto irá necessitar, para sua execução, de uma equipe composta por 6 pessoas
durante 5 semanas. Vale ressaltar que a alocação média das pessoas é de 8 horas por semana.
3.2 Prazos

O prazo de entrega da solução é contado a partir da data de validação desta proposta, com
previsão de término para 01/07/2015. Sendo o formato de data DD/MM/AAAA.

3.3 Propriedade e Licença

9
 O Contratante terá direito de uso ao aplicativo desenvolvido bem como às fontes do
mesmo, que serão publicados como software livre, pois o aplicativo utilizará ferramentas,
padrões, templates, guias, métodos e técnicas “free”. O banco de dados com as informações
da Contratante, entretanto, é de sua propriedade, podendo a Contratante utilizá-lo livremente.
O Aluno não terá nenhuma licença ou direitos a estes ativos, exceto se especificado e
estabelecido nesta Proposta.
3.4 Composição da equipe da Lemag

Os seguintes perfis compõem a Lemag:

• Gerente de Projetos
• Gerente Comercial
• Analista de Negócios
• Engenheiro de Qualidade
• Engenheiro de Software
• Arquiteto de Software
• Designer

3.5 Metodologias Utilizadas

• Qualidade do Produto e do Software

A Qualidade de Pacotes de Software segundo ISO 12119 foi publicada em 1994 e trata
da avaliação de pacotes de software. Um pacote de software está em conformidade com
essa Norma Internacional se ele cumpre com todos os requisitos de qualidade relacionados
à Descrição do Produto, Documentação do Usuário, Programas e Dados.
Como forma de garantia da qualidade do processo, sugerimos a adoção do PSP. O PSP
(Personal Software Process) prove um método de trabalho que ensina um processo de
software aos engenheiros, e o ponto de partida é fazer com que o engenheiro se envolva
em seu próprio processo. O PSP é baseado nas mesmas práticas industriais encontradas no
CMM da SEI, só que em uma escala menor para o uso individual. A ideia principal do
PSP é criar módulos ou pequenos programas com alta qualidade.
Os objetivos principais do PSP são:
o Melhorar as estimativas
o Melhorar o planejamento e o acompanhamento de cronogramas
o Proteger contra o excesso de compromissos
10
 o Criar um comprometimento pessoal para a qualidade

• Gerência de Projeto
O processo de gerência de projetos é parte integrante do processo de desenvolvimento
de software, mas se distingue por ser um fluxo que permeia todos os demais, desde o
início ao fim do projeto, com o objetivo de atender aos requisitos de escopo, prazo,
qualidade e custo do mesmo.
O PMBOK (Project Management Book of Knowledge) considera 9 áreas de
conhecimento na gerência de projetos: Integração, Escopo, Tempo, Custo, Qualidade,
Recursos Humanos, Comunicações, Riscos e Aquisições. Estas áreas de conhecimento
descrevem os conhecimentos e práticas em gerência de projetos em termos dos processos
que as compõem. Estes processos podem ser organizados em cinco grupos, cada um deles
contendo um ou mais processos.

• Arquitetura de Software
Arquitetura de software da Lemag será baseada de acordo com a plataforma de
desenvolvimento e do produto a ser desenvolvido. Independente da plataforma a ser
escolhido algum aspecto da arquitetura deve ser considerado.
Cada camada deverá prover funções especificas do aplicativo, a forma de
comunicação entre elas deverá ser sempre no sentido Interface -> Comunicação ->
Negocio -> Dados.

• Modelo do Banco de Dados

Essa aplicação será livre de plataforma e poderá rodar em qualquer tipo de banco de
dados relacional, pois as operações utilizadas no aplicativo usarão SQL padrão.

• Descrição do Ambiente de Configuração

A estrutura física de desenvolvimento será distribuída, onde cada membro da Lemag
poderá trabalhar em um lugar diferente, porém todos os itens de configuração deverão ser
mantidos em um repositório central onde será feito o controle de versões e mudanças.
Utilizando ferramentas como Código LivreErro! Fonte de referência não encontrada. é um serviço
gratuito em português para desenvolvedores de software que oferece fácil acesso a CVS,
listas, controle de bugs, quadro de mensagens/fórums, gerenciador de tarefas,

11
 hospedagem, arquivamento permanente de arquivos, backups completos e administração
totalmente baseada na WEB.
• Fases X Artefatos
A tabela abaixo lista os artefatos gerados por fase da metodologia

Fase Artefatos Disponibilização no Site

Comercial • Documento de Requisitos • 28/05/15

• Cronograma Proposta • 29/05/15
• Resposta a RFP • 01/05/15
• Estimativa de Esforço • 29/05/15
• Estimativa de Custos • 29/05/15
• Proposta Técnica • 30/05/15
• Proposta Comercial • 31/05/15
• Contrato de Software • 01/06/15

Planejamento • Ata de reunião • 04/06/15, 11/06/15,

e 18/06/15, 25/06/15
Gerenciament • 04/06/15
o • 06/06/15
• Plano do Projeto
• 06/06/15
• Cronograma Projeto
• 29/06/15
• Relatório de Riscos Identificados
• 11/06/15, 25/06/15
• Planilha de Reportagem de Tempo
• 01/07/15
• Planilha de Acompanhamento de
• 29/06/15
Custos
• Relatório de Conclusão de Projeto
• Tamanho Final em Pontos de
Casos de Uso
Testes e • Descrição de Testes de Aceitação • 06/06/15
Validação • 26/06/15
• 28/06/15
• Código de Testes de Unidade

12
 • Registro de Erros

• S.L.A. - Acordo de nível de serviço

A Lemag se compromete a prestar serviços de Desenvolvimento de Software para a
DESMIL, no sentido de desenvolver uma solução para manter informações sobre os alunos
desta instituição.

Na conclusão do projeto será feito um balanço das multas e descontos devidos às

penalidades aplicadas para gerar o custo final do projeto, não podendo o custo final
ultrapassar uma variação de 30% no valor estimado do projeto, salvo custos gerados por
solicitações de mudanças.

3.6 Itens acordados para eventuais cobranças

• Dos prazos

De acordo com a proposta técnica, a Lemag se compromete a entregar diversos artefatos

ao cliente (inclusive o projeto final). O cliente deverá rejeitá-los em até 48hs contadas a partir
do recebimento. Após este prazo os artefatos serão considerados aceitos. No caso de rejeição
e descumprimento do prazo, o cliente terá um ônus de 0.5% por dia de atraso no valor do
projeto mais o custo de retrabalho (se existir). Caso o atraso seja da Lemag, o cliente receberá
um desconto de igual valor. Artefatos entregues antes do prazo, gradualmente cancelam os
descontos provenientes de atrasos em outros artefatos na medida de um dia de adiantamento
para um dia de atraso.
Este mesmo encargo é válido para qualquer artefato com prazo de entrega estabelecida
para qualquer uma das partes, ou seja, as penalidades aplicam-se também aos prazos
estabelecidos para solicitações feitas ao cliente e que dependam do mesmo.

• Das reuniões com o cliente

Qualquer uma das partes pode solicitar reuniões durante o desenvolvimento do projeto. O
cliente deve ter agilidade na resposta a e-mails que solicitem tais reuniões, será cobrada uma
multa de 1% sobre o valor do projeto por dia, caso a resposta ultrapasse o prazo de 48hs.
Ambos têm que concordar sobre o horário e local dessa reunião. O não comparecimento de
13
qualquer das partes fica sujeito à penalidade de 1% sobre o valor do projeto por
descumprimento de compromisso para a parte ausente.
O cliente deverá dispor de pelo menos uma hora semanal a ser utilizada quando necessário
para realização de esclarecimentos sobre o projeto e seu andamento.

• Da Qualidade

A Lemag garante a qualidade do produto e produz um relatório de métricas ao final do

projeto. A não aderência ao processo de qualidade definido pela Lemag implica no desconto
de 5% sobre o valor do projeto. A Lemag garante entregar o produto com no máximo 3 bugs a
cada 1000 linhas de código, sendo este o principal indicador de qualidade.

Fica estabelecido o desconto de 0.5% sobre o valor do projeto por cada 30% de bugs a
mais que o especificado.

• Das Mudanças

As solicitações de mudança (escopo, SLA, etc.) só serão consideradas se enviadas por

e-mail para o gerente de projeto e devem ser bem descritas e justificadas.

A Lemag tem 48hs para responder por e-mail com uma proposta de possível solução
de atendimento ao cliente, contendo as modificações necessárias em cronogramas e encargos
juntamente com sua justificativa.

Os encargos referentes a estudos de viabilidade são pagos pelo cliente na forma de

uma multa de 1% do valor do projeto por solicitação de mudança.

14
 3.7 Termo de Abertura de Projeto (TAP)

Aplicativo Desmil
TERMO DE ABERTURA
PROJECT CHARTER*
Preparado por Daniela, Érika, Igor e Suzan Versão 1.0
Aprovado por Leidy e Magno 27/04/2015

1. TITULO DO PROJETO E DESCRIÇÃO

Aplicativo Desmil: deve permitir que os alunos trabalhem de forma colaborativa
para a resolução de uma determinada tarefa bem como o seu acompanhamento.

2. GERENTE DE PROJETOS DESIGNADO E NÍVEL DE AUTORIDADE

Magno será o gerente do projeto e tem autoridade para selecionar o seu pessoal e
determinar o orçamento para este projeto.

3. MOTIVAÇÃO
Este projeto está sendo conduzido a fim de alavancar ainda mais o nome da Lemag
no seguimento de aplicativos móveis. Esperamos que uma melhoria no processo
aumente a lucratividade e eficiência da empresa, pois teremos um curto espaço de
tempo para implementação.

4. OBJETIVOS DO PROJETO
O objetivo deste projeto é melhorar a satisfação do cliente ao reduzir o tempo de
realização dos pedidos em 10% em relação ao tempo atual, dentro de um
orçamento preestabelecido e com um prazo de conclusão de até 01 de julho de
2015.

5. ENTREGAS PRINCIPAIS DO PROJETO

• Avaliação detalhada da situação atual
• Entrevistas com colaboradores e clientes
• Relatório com recomendações de soluções para o problema.

6. RECURSOS PRÉ-ALOCADOS
O departamento de marketing estará disponibilizando dois gerentes de produto e o
de TI, dois analistas de sistemas.

7. STAKEHOLDERS/PARTES INTERESSADAS
Os stakeholders incluem Érika - Controle de Qualidade, Daniela - Serviço de
Suporte ao Cliente e Suzan – Marketing. Esses recursos estarão disponíveis para
auxiliar o projeto no que for necessário e solicitado pelo Gerente de Projetos.

8. REQUISITOS CONHECIDOS DOS STAKEHOLDERS

O relatório de recomendações deverá seguir o modelo/template conforme
diretrizes do PMO, incluindo informações detalhadas relativas a custo em formato

15
 de planilha Excel e cronograma em MS Project. Uma cópia eletrônica do relatório
final deverá ficar disponível no servidor DOCS do departamento de TI.

9. PREMISSAS/RESTRIÇÕES BÁSICAS
O orçamento para o projeto já está aprovado pela Diretoria. Os departamentos de
marketing e TI darão apoio ao projeto até a conclusão do mesmo. Necessidades
conflitantes com relação aos recursos do projeto e prioridades entre este e outros
projetos serão resolvidas pelo PMO. Este projeto deve ser aprovado até 28 de abril
deste ano.

10. RISCOS INICIAIS

- Devido ao pouco tempo para a implementação, pode causar atrasos junto aos
clientes.
- Caso não consiga finalizar a tempo, um atraso no projeto poderia gerar perdas
adicionais à empresa.

APROVAÇÕES
Magno xxxxxxxxxxx 27/04/2015

4. Planejamento

4.1 Levantamento e análise de requisitos (funcionais e não funcionais)

• Requisitos Funcionais
o Alavancar ainda mais o nome da Lemag no seguimento de aplicativos móveis.
o Melhoria no processo
o Aumento na lucratividade e eficiência da empresa

• Requisitos Não-funcionais
o Pouco tempo para a implementação.
o Pode gerar atrasos junto ao cliente

16
4.2 Diagrama de caso de uso

17
4.3 Diagrama de Classe

18
4.4 Diagramas de sequência

19
20
4.5 Estrutura Analítica do Projeto (EAP)

21
 4.6 Plano de Gerenciamento de Qualidade do Projeto (SCRUM)

• Papéis

Proprietário do Produto: Magno Soares

ScrumMaster: Leidy Carla
Equipe de Desenvolvimento: Erika, Josevaldo, Suzan e Daniela

• Escopo do Projeto

Após várias visitas junto ao cliente e verificados os requisitos, o proprietário do produto

definiu o escopo do projeto:

“Este aplicativo deve permitir que os alunos trabalhem de forma colaborativa para a resolução
de uma determinada tarefa bem como o seu acompanhamento.

O sistema desenvolvido terá como principais funcionalidades o compartilhamento para o

grupo das versões mais recentes da atividade, bem como uma notificação de atualização de
material a cada nova postagem. Uma versão individual do trabalho é disponibilizada bem
como o seu histórico de alterações, além de uma versão colaborativa, ou seja, aquela que
contempla todas as atualizações de acordo com a ordem de alteração do arquivo, por hora e
data”.

• Product Backlog

Após o levantamento das funcionalidades feito pelo Proprietário do Produto, o Product

Backlog foi montado, definindo as prioridades de acordo com a importância para o cliente.
Usaremos a notação de 1 a 5, quanto maior o número, menor a prioridade (1-prioridade
máxima, 2-prioridade menor..., 99-proridade nula).

22
 Funcionalidade Prioridade
Modelagem de Dados 1
Cadastro e Gerenciamento de usuários 2
Cadastro e Gerenciamento de grupos de
3
compartilhamento
Gerenciamento de compartilhamento de arquivos 4
Gerenciamento de notificações 5
Layout da página 6

• Reunião de Planejamento do Sprint

Após a reunião de planejamento, o Proprietário do Produto apresentou o projeto aos demais

membros da equipe e toda a equipe definiu a quantidade de horas que cada tarefa deverá
ocupar, estimando o custo/hora:

Funcionalidade Prioridade Custo/hora

Modelagem de Dados 1 40
Cadastro e Gerenciamento de usuários 2 54
Cadastro e Gerenciamento de grupos de
3 45
compartilhamento
Gerenciamento de compartilhamento de arquivos 4 35
Gerenciamento de notificações 5 42
Layout da página 6 57

Definiu-se que teremos 3 Sprints, sendo:

Sprint 1:
o Modelagem de Dados
o Cadastro e Gerenciamento de usuários
o
Sprint 2:

23
 o Cadastro e Gerenciamento de arquivos compartilhados
o Gerenciamento de compartilhamento de arquivos

Sprint 3:
o Gerenciamento de notificações
o Layout da página

• Sprint Backlogs

Após feita a divisão dos Sprints, o ScrumMaster, junto à equipe de desenvolvimento, definiu
o Sprint Backlog, subdividindo as tarefas em tarefas menores:

Sprint 1:
Funcionalidade Prioridade Custo/hora
Modelagem de Dados 1 40
Definição de Dados 1.1 8
Organização de Tabelas 1.2 15
Relacionamento 1.3 10
Implementação SGBD 1.4 7
Cadastro e Gerenciamento de usuários 2 54
Formulários 2.1 16
Interação com cadastro na base de dados 2.2 14
Definição de perfil 2.3 14
Alteração de dados 2.4 5
Relacionamento entre usuários 2.5 5

24
Sprint 2:
Funcionalidade Prioridade Custo/hora
Cadastro e Gerenciamento de grupo de
3 45
compartilhamento
Formulários 3.1 13
Interação com cadastro na base de dados 3.2 8
Associação com usuários 3.3 9
Alteração de dados 3.4 15
Gerenciamento de compartilhamento de arquivos 4 42
Associação de arquivo com grupo 4.1 9
Interação com cadastro da base de dados 4.2 11
Gravação e visualização de alterações em
4.3 13
histórico
Disponibilização de versão individual e
4.4 11
colaborativa

Sprint 3:
Funcionalidade Prioridade Custo/hora
Gerenciamento de notificações 5 42
Envio de mensagem padrão para usuário
5.1 12
alterador
Envio de mensagem padrão para administrador 5.2 12
Envio de mensagem padrão para grupo 5.3 12
Alteração de dados 5.4 6
Layout da página 6 57
Telas do módulo de Gerenciamento de usuários 6.1 20
Tela do módulo de Gerenciamento de grupos 6.2 15
Tela de visualização de histórico 6.3 15

25
 Tela de alteração de notificação 6.4 7

• Início do Sprint

Durante o ciclo de cada Sprint, a equipe de desenvolvimento irá trabalhar na execução das
tarefas de acordo com o seguinte subciclo:

Desenvolver o produto: implementar, testar e documentar;

Empacotar: deixar o produto pronto para ser apresentado e integrado;
Revisar: conferir o trabalho, certificando do que foi feito;
Ajustar: adaptar qualquer mudança nos planos ou requisitos.

• Reuniões diárias

O ScrumMaster irá acompanhar se a equipe de desenvolvimento está completando as tarefas

de acordo com o plano, através de reuniões diárias, mantendo a equipe completa,
comprometida e com foco no projeto.

• Burndown Chart

Por meio das informações obtidas durante as reuniões diárias do Sprint, o ScrumMaster
poderá alimentar o Burndown Chart, que graficamente irá exibir de forma clara, o andamento
do projeto ao longo do seu ciclo. Desta forma, toda a equipe pode ter uma ideia clara do
andamento do processo. Este gráfico pode ser mostrado ao Proprietário do Produto para que
ele também acompanhe o andamento do projeto.

26
 Desenvolvimento do Projeto

As atividades foram desenvolvidas de forma participativa. Todos os envolvidos puderam

obter diversos conhecimentos sobre as técnicas para um bom planejamento do projeto e
desenvolvimento do sistema.

Para a tomada de decisão racional e definição dos riscos e benefícios, fez-se o uso RFP
(proposta de solicitação). Após análise da RFP foi feito o TAP - Termo de Autorização de
Projeto, autorizando formalmente o andamento e definições do projeto.

Todo o escopo do projeto foi desenvolvido de maneira clara e eficiente através do uso de
diagramas de Caso de uso, Diagramas de Sequência e Diagramas de Classe para cada
funcionalidade do sistema, mantendo assim uma documentação clara e definida do que deve
ser feito pela equipe desenvolvedora.

Para que o projeto fosse bem elaborado e atingisse as metas definidas, utilizamos a técnica de
gerenciamento SCRUM que possibilitou o acompanhamento de todo o processo por todos os
envolvidos. Através das reuniões diárias foi possível reorganizar as atividades, quando
necessárias, mantendo sempre o Burndown Chart alimentado e disponível para visualização
pela equipe durante todo o clico, permitindo assim o cumprimento de prazos e mantendo desta
forma o cronograma em dia.

Desta maneira, através de um bom gerenciamento e de empenho da equipe, o projeto foi

concluído com total êxito. Foram feitas entrevistas e visitas pós-implantação para que fosse
registrada a satisfação do cliente com o funcionamento do aplicativo.

27
 Conclusão

Em apresentação do plano de gerenciamento e controle do projeto, atingimos as expectativas

e necessidades do Cliente, utilizando das melhores ferramentas disponíveis que melhor
comportará todo o projeto e conclusão do mesmo, reduzindo a utilização de recursos e
otimizando os prazos.

O monitoramento continuará para próxima etapa, onde executaremos efetivamente todas as

atividades mapeadas até o momento, distribuindo assim todas as funcionalidades do
aplicativo.

28
Bibliografia:
http://www.devin.com.br/modelo-scrum/
http://www.linhadecodigo.com.br/artigo/2084/uma-metodologia-agil-scrum.aspx
https://www.youtube.com
http://www.elirodrigues.com/2012/10/19/como-fazer-uma-rfp/
http://en.wikipedia.org/wiki/Request_for_proposal
http://www.mindmaster.com.br/scrum/
http://www.ufpi.br/subsiteFiles/rbritto/arquivos/files/Aula05_Criando%20o%20Termo%20de
%20Abertura%20III.pdf
https://www.microsoft.com/brasil/msdn/Tecnologias/Carreira/GerencProjetos.mspx
http://www.devmedia.com.br/curso/curso-de-gerenciamento-de-projetos-pmbok/396

29