Modelo plano projeto de sw oo

UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Sistema Eletrônico de Informação e Comunicação com o Cidadão - SICC
Plano de Projeto de Software
Anselmo Rodrigues, Francyelle Mascarenhas, Michael Mendonça
São Cristóvão – SE
2018

UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Anselmo Rodrigues, Francyelle Mascarenhas, Michael Mendonça
Sistema Eletrônico de Informação e Comunicação com o Cidadão - SICC
Plano de Projeto de Software realizado para a
matéria de Gestão de Projeto da Universidade
Federal de Sergipe
Professor: Dr. Rogério Patrício Chagas do
Nascimento
São Cristóvão – SE
2018
1

Lista de Figuras
Figura 1 - Diagrama de casos de uso 8
Figura 2 - Diagrama de classes de projeto 11
Figura 3 - Diagrama de Gantt 24
2

Lista de Quadros
Quadro 1 - Multiplicador por tipo de interface do projet 11
Quadro 2 - Resultados da técnica de Lorenz & Kidd 12
Quadro 3 - Estimativas de dias de trabalho por fase do projeto 13
Quadro 4 - Informações técnicas dos computadores utilizados 14
Quadro 5 - Riscos do projeto 15
Quadro 6 - Impacto e probabilidade de riscos do projeto 16
Quadro 7 - Risco 1 - Não cumprimento da Lei de Acesso à Informação 17
Quadro 8 - Risco 2 - Saída de pessoal da equipe do projeto 17
Quadro 10 - Risco 4 - Mudança dos requisitos 18
Quadro 11 - Risco 5 - Confusão no levantamento de requisitos 19
Quadro 12 - Risco 6 - Cliente não participa dos reviews 19
Quadro 13 - Risco 7 - Má execução dos requisitos 20
Quadro 14 - Risco 8 - Mal relacionamento com o cliente 20
Quadro 15 - Risco 9 - Não aplicação do fluxo de processo definido 21
Quadro 16 - Risco 10 - Atraso devido à equipe trabalhar meio período 21
Quadro 17 - Risco 11 - Comprometimento da equipe 22
Quadro 18 - Risco 12 - Número de Cliente que usarão o projeto 22
Quadro 19 - Tempo estimado em cada tarefa 23
Quadro 20 - Integrantes da equipe e suas funções 25
3

Lista de Abreviaturas e Siglas
LAI - Lei de Acesso à Informação
RAM - Random Access Memory
SICC - Sistema Eletrônico de Informação e Comunicação com o Cidadão
UFS - Universidade Federal de Sergipe
4

Sumário
1.0 Introdução 7
1.1 Escopo do projeto 7
1.2 Funções principais do produto de software 7
1.3 Requisitos comportamentais ou de performance 9
2.0 Estimação do Projeto 9
2.1 Dados históricos utilizados para as estimações 9
2.2 Técnicas de estimação e resultados 9
2.2.1 Técnica de estimação 9
2.3 Resultado
2.4 Recursos do projeto 13
2.4.1 Recursos Humanos 13
2.4.2 Recursos de Software 13
2.4.3 Recursos de Hardware 13
3.0 Análise e Gestão de Riscos 14
3.1 Riscos do Projeto 14
3.2 Tabela de Riscos 16
3.3 Redução e Gestão de Risco 16
4.0 Planejamento Temporal 22
4.1 Conjunto de Tarefas do Projeto 22
4.2 Diagrama de Gantt 23
5.0 Organização da Equipe 23
5.1 Estrutura da Equipe 23
5.2 Mecanismos de Comunicação 24
5.3 Uso do Edu-blog como ferramenta de apoio 25
6.0 Precauções tomadas para assegurar e controlar a qualidade do produto de Software 25
7.0 Referências 26
5

1.0 Introdução
O objetivo deste documento é definir detalhadamente fatores relevantes de planejamento,
execução e acompanhamento do desenvolvimento do projeto Sistema Eletrônico de Informação e
Comunicação com o Cidadão - SICC . Estes fatores abrangem principalmente escopo, prazo,
recursos, qualidade e riscos.
1.1 Escopo do projeto
O escopo deste sistema abrange um meio de comunicação entre o cidadão e os órgãos de
governo estadual, seguindo as normas previstas na Lei de Acesso à Informação - LAI
(Lei Federal Nº 12.527). A lei foi regulamentada no Governo Federal pelo decreto nº
7.724/2012 e no Governo de Sergipe pelo decreto Nº 30.947/2017.
1.2 Funções principais do produto de software
As principais funções empregadas pelo software abrangem os tópicos a seguir:
● Cadastro de cidadãos.
Os cidadãos podem se cadastrar no sistema para realizar solicitações aos órgãos.
● Cadastro de órgãos/entidades e representantes.
O administrador tem o poder para cadastrar novos órgãos governamentais e seus
funcionários que agirão como representantes da comunicação cidadão-estado.
● Realização de mensagens.
O sistema deve possibilitar a realização de mensagens através de solicitações de
cidadãos aos órgãos desejados.
● Gestão de fluxo de solicitação
O sistema deve gerir os prazos e fluxo de encaminhamento das solicitações de
acordo com seu tipo.
6

Essas funções são mais fáceis de se compreender ao interpretarmos o Diagrama de Caso
de Uso do Sistema, exibido na Figura 1. Um diagrama de Caso de Uso descreve um
cenário que mostra as funcionalidades do sistema do ponto de vista do usuário
(SAMPAIO, 2007). Na Figura 1 temos o ator Usuário que possui três especificações:
Responsável, Gestor e Cidadão. Os atores Responsável e Gestor são responsáveis por
Atender Solicitação, que consiste em ler, responder ou encaminhar para o órgão devido as
solicitações enviadas pelo Cidadão. Além de atender solicitações o Gestor é responsável
por Manutenir Responsável, que consiste em cadastrar, alterar e excluir instâncias dos
atores classificados como Responsável; Manutenir Entidades, que consiste em cadastrar,
alterar e excluir instâncias dos Órgãos/Entidades do Governo de Sergipe; Manutenir
Ações, que consiste em cadastrar, alterar e excluir instâncias das ações referentes às
entidades do Governo. O ator Cidadão é responsável por Realizar Solicitações, como já
comentamos, essas solicitações podem ser pedidos de informação, solicitações, sugestões,
elogios, denúncias ou reclamações. Estas solicitações serão atendidas pelo Responsável
ou pelo Gestor. Cidadão também responde pelo Manutenir Cidadão, que consiste em
cadastrar, alterar e inativar seu cadastro como Cidadão. Há ainda outro ator, Sistema,
responsável por Gerar Relatório, Gerar Alerta e Gerenciar Prazo. No diagrama podemos
ver que Atender Solicitação destaca-se dos outros em vermelho. Isso ocorre devido a essa
ser a parte de maior prioridade do sistema.
Figura 1 - Diagrama de casos de uso
7

1.3 Requisitos comportamentais ou de performance
O sistema possui os seguintes requisitos comportamentais ou de performance:
● Usabilidade
Interface com o usuário - o sistema deve apresentar uma interface intuitiva, utilizando-se
de ícones que facilitem seu entendimento pelo usuário.
● Confiabilidade
Consistência dos dados - os dados não podem, em hipótese alguma, ser corrompidos ou
excluídos por falhas do sistema.
1.4 Gestão e Restrições Técnicas
As restrições técnicas associadas ao projeto são:
● A linguagem de programação utilizada é Java.
● As atividades de desenvolvimento devem ser coordenadas através do TRELLO.
2.0 Estimação do Projeto
Esta seção fornece as estimações de custo, esforço e tempo. As estimativas foram calculadas
baseadas nas métricas de Lorenz & Kidd.
2.1 Dados históricos utilizados para as estimações
Por ser o primeiro projeto da equipe, não foi possível utilizar dados históricos nas
estimações.
2.2 Técnicas de estimação e resultados
2.2.1 Técnica de estimação
Este projeto utilizará a técnica orientada a classes de Lorenz & Kidd. Conforme
Lorenz e Kidd (1994), o tamanho de uma classe é medido a partir da métrica
Class Size (CS). Essa métrica conta o número total de operações e número de
atributos que são encapsulados dentro de uma classe. Grandes valores de CS
8

podem significar que uma classe possui grande responsabilidade, o que pode
ocasionar baixa reusabilidade, alta complexidade de implementação, manutenção
e testes (PRESSMAN, 2005)
A técnica de métrica de Lorenz & Kidd(1994) é caracterizado pelos seguintes
passos:
1. Definir o número de classes chave;
2. Encontrar o número de classes de suporte, que para isso temos que
classificar o tipo de Interface do Produto e desenvolver um Multiplicador
para as Classes de Suporte;
3. Multiplicar a quantidade de classes-chave pelo Multiplicador para obter
uma estimação do número de classes de suporte;
4. De seguida, calcula-se a quantidade total de Classes, somando o nº de
classes-chave com o nº de Classes de Suporte;
5. Multiplicar a quantidade total de Classes (classes-chave + classes de
suporte) pelo número médio de unidades de trabalho (dias-pessoa) por
classe (Lorenz & Kidd sugere entre 15 e 20 dias-pessoa por classe.
Escolher um número entre 15-20 dias-pessoa e justificar a escolha;)
6. Determinar a quantidade de esforço estimada;
7. Cálculo do tempo previsto para a elaboração do projeto;
No Quadro 1 podemos ver o multiplicador por tipo de interface utilizado no
projeto do SIIC. Para interface não gráfica o multiplicador definido foi 2; já para
interface baseada em texto 2,25; GUI simples foi estabelecido como 2,5 e GUI
complexa 3.
Quadro 1 - Multiplicador por tipo de interface do projeto
Interface Multiplicador
Não gráfica 2
Baseada em texto 2,25
GUI simples 2,5
GUI complexa 3
9

2.3 Resultado
Para aplicar os passos mencionados no tópico 2.2.1 foi preciso modelar o Diagrama de
Classes de projeto. O resultado da modelagem foi disponibilizado na Figura 2. Foram
levantadas 9 classes chaves para projeto.
Figura 2 - Diagrama de classes de projeto
Aplicando o processo de métrica de Lorenz & Kidd obtivemos os seguintes resultados:
1. Número de classes chave é 9;
2. Pela natureza do projeto a interface é classificada como GUI
Simples, logo o multiplicador é 2,5.
3. O número de Classes de Suporte será 9*2,5 = 22,5 classes
(multiplicador * número de Classes chave).
4. A quantidade total de Classes será 9+22,5 = 31,5 classes (número
de classes chave + número de Classes de Suporte).
5. A unidade de trabalho será de 20 dias-pessoa por classe devido à
ausência de familiaridade com a linguagem.
6. A quantidade de esforço será 31,5*20 = 630 dias de trabalho
(número total de classes * unidade de trabalho).
7. Sendo assim o tempo previsto para a elaboração do projeto é de
630/3 = 210 dias por pessoa. (Dias de trabalho/Quantidade de pessoas).
10

No Quadro 2 podemos verificar de forma mais direta os resultados acima explicados.
Quadro 2 - Resultados da técnica de Lorenz & Kidd
Resultado
Classes chave 9
Natureza do projeto GUI simples
Multiplicador 2,5
Classes de suporte 22,5
Total de classes projetadas 31,5
Unidades de trabalho 20 dias/pessoa
Esforço estimado 630 dias
Dias de trabalho por
membro da equipe
210 dias
Fonte: Autores
Visto ser o primeiro projeto da equipe foi estipulado o “número médio de unidades de
trabalho (dias-pessoa)” de 20 dias-pessoa, obtendo assim, junto do total de classes
projetados estipuladas, o total de 620 dias de esforço estimado. A partir disso, o esforço
estimado foi dividido igualmente entre os 3 membros da equipe, obtendo o total de 207
dias de trabalho por membro.
Ao aplicar a distribuição dos dias de trabalho ao percentual de cada fase do projeto,
obteve-se o resultado mostrado no Quadro 3. Foi estabelecido que a etapa de
planejamento representaria 3% do tempo do projeto. A etapa de Levantamento de
Requisitos, Análise e Desenho ou Modelagem representará 40% do tempo de trabalho. A
Codificação terá um percentual igual a 20 e os Testes 37% dos dias de trabalho. Podemos
ver, como já mencionamos, o resultado no Quadro 3.
11

Quadro 3 - Estimativas de dias de trabalho por fase do projeto
Etapa Modelo (%) Projeto (%) Cálculo Dias de Trabalho
Planejamento 2-3 3 210 * 0,03 6,3
Requisito-Análise-D
esenho
40 40 210 * 0,4 84
Codificação 20 20 210 * 0,2 42
Testes 37-38 37 210 * 0,37 77,7
Total 210
Fonte: Autores
2.4 Recursos do projeto
2.4.1 Recursos Humanos
A equipe deste projeto é composta por Anselmo Rodrigues, Francyelle Mascarenhas e
Michael Mendonça, graduandos no Bacharelado de Sistemas de Informação pela
Universidade Federal de Sergipe (UFS).
2.4.2 Recursos de Software
O projeto utiliza dos seguintes softwares:
● Eclipse: IDE utilizada na codificação do software.
● Mysql: gerência do banco de dados utilizado no projeto
● Git: Sistema de controle de versão a ser utilizado para permitir desenvolvimento
distribuído do software
2.4.3 Recursos de Hardware
Os recursos de hardware disponíveis são compostos por três computadores (com as
especificações descritas no Quadro 4) e um servidor.
12

Quadro 4 - Informações técnicas dos computadores utilizados
Fabricante Daten Tecnologia Ltda
Processador AMD A8-7600 Radeon R7, 10 Compute Cores 4C+6G,
3.10 GHz
RAM 8 GB (6,93 GB utilizáveis)
Sistema Operacional Windows 7 (64 Bits)
Fonte: Autores
3.0 Análise e Gestão de Riscos
Nesta seção, serão apresentados os possíveis riscos do projeto e também como esses riscos serão
gerenciados.
3.1 Riscos do Projeto
Os riscos de projeto ameaçam o plano do projeto, podendo atrasar o cronograma e
aumentar custos. Os riscos técnicos ameaçam a pontualidade e a qualidade do software,
tornando a implementação impossível. Já os riscos do negócio ameaçam a viabilidade do
software a ser criado. Riscos comuns são os previsíveis, enquanto os especiais são
imprevisíveis (ISOTANI & ROCHA).
O primeiro risco identificado foi o “Não cumprimento da Lei de Acesso à Informação”
classificado como um risco de negócio pois afeta diretamente a viabilidade do software
ser criado.
Os riscos “Confusão no levantamento de requisitos” e “Mal relacionamento com o
cliente” foram definidos como riscos de projeto pois podem atrasar o cronograma do
projeto já que a confusão no levantamento de requisitos e má relação com o cliente criam
barreiras na comunicação, o que pode afetar no que deve ser realizado no projeto.
Já os riscos “Instabilidade do database” e “Comprometimento da equipe” são
classificados como riscos técnicos pois impedem o desenvolvimento do projeto e
reduzem a qualidade dele.
A “Saída de pessoal da equipe do projeto” e “Mudança dos requisitos PE” foram
identificados como riscos de projeto e simultaneamente riscos especiais por poderem
atrasar o cronograma do projeto e serem imprevisíveis.
13

Foram definidos como riscos de projeto e técnicos os riscos “Má execução dos
requisitos” e “Não aplicação do fluxo de processo definido” por além de gerar atrasos e
aumentar o custo do projeto, impedem também o seu desenvolvimento.
Por fim temos os riscos “Número de clientes que usarão o projeto”, “Atraso devido à
equipe trabalhar meio período” e “Cliente não participa dos reviews” são riscos
classificados como técnico e comum por gerarem queda na qualidade do projeto,
entretanto são riscos previsíveis.
No Quadro 5 mostramos esses riscos e suas classificações por categoria (projeto, técnico,
negócio, comum, especial).
Quadro 5 - Riscos do projeto
Risco Projeto Técnico Negócio Comum Especial
Não cumprimento da Lei de Acesso à
Informação. X
Saída de pessoal da equipe do projeto. X X
Instabilidade do database X X
Mudança dos requisitos. X X
Confusão no levantamento de requisitos. X
Cliente não participa dos reviews. X X
Má execução dos requisitos. X X
Mal relacionamento com o cliente. X
Não aplicação do fluxo de processo definido. X X
Atraso devido à equipe trabalhar meio período. X X
Comprometimento da equipe. X
Número de clientes que usarão o projeto. X X
Fonte: Autores
14

3.2 Tabela de Riscos
A tabela de riscos que identifica o impacto e probabilidade de ocorrência por riscos está
descrita no Quadro 6, onde é informado o nome dos riscos levantados, a categoria, a
probabilidade de ocorrência e o seu impacto.
Quadro 6 - Impacto e probabilidade de riscos do projeto
Risco Impacto Probabilidade
001 Não cumprimento da Lei de Acesso à Informação Catastrófico 20%
002 Saída de pessoal da equipe do projeto Crítico 60%
003 Instabilidade do database Crítico 50%
004 Mudança dos requisitos Crítico 21%
005 Confusão no levantamento de requisitos Crítico 20%
006 Cliente não participa dos reviews Crítico 15%
007 Má execução dos requisitos Crítico 10%
008 Mal relacionamento com o cliente Crítico 10%
009 Não aplicação do fluxo de processo definido Crítico 10%
Ponto de Corte
010 Atraso devido à equipe trabalhar meio período Marginal 55%
011 Comprometimento da equipe Marginal 40%
012 Número de Cliente que usarão o projeto Marginal 40%
Fonte: Autores
3.3 Redução e Gestão de Risco
Nesta seção, serão apresentados os possíveis riscos do projeto e como serão gerenciados.
É fundamental elaborar de estratégias de redução e planos de contingência na busca de
minimizar as chances dos riscos em questão se tornarem reais ou reduzir seus impactos.
Abaixo temos doze quadros nos quais abordamos os riscos, e informações e estratégias
de redução, planos de contingência e identicação dos responsáveis pela ativação do
plano.
15

Quadro 7 - Risco 1 - Não cumprimento da Lei de Acesso à Informação
Risco: Não cumprimento da Lei de Acesso à Informação
Código: 001 Probabilidade: 20% Impacto: Catastrófico
Descrição: A Lei nº 12.527/2011 regulamenta o direito constitucional de acesso às
informações públicas, e seu não cumprimento pode resultar em um processo de
sindicância para um órgão e seu representante.
Estratégia de Redução: Estabelecer e detalhar os requisitos do projeto previamente
de forma a cumprir as exigências legais, quanto ao recebimento, tempo e forma de
resposta das solicitações realizadas pelos cidadãos.
Plano de Contingência: Realizar reuniões para definir bem os requisitos do sistema,
adaptando-se às possíveis mudanças da LAI. Mantendo-se atento aos novos decretos e
leis que se relacionem à Lei de Acesso a Informação.
Pessoa Responsável: Michael Mendonça
Status: Simulação completa
Quadro 8 - Risco 2 - Saída de pessoal da equipe do projeto
Risco: Saída de pessoal da equipe do projeto
Código: 002 Probabilidade: 60% Impacto: Crítico
Descrição: Alta rotatividade de funcionários.
Estratégia de Redução: Documentar os requisitos e processos do software para
manter novos membros atualizados com o projeto. Manter um quadro reserva para
possíveis substituições.
Plano de Contingência: Realizar nova seleção de pessoal para a equipe, durante o
aviso prévio do membro que irá se retirar.
Pessoa Responsável: Michael Mendonça
16

Quadro 9 - Risco 3 - Instabilidade do database
Risco: Instabilidade do database
Descrição: Database inoperante quando requisitado. A instabilidade pode ocorrer
devido a falhas de hardware ou software do sistema de armazenamento, ou da própria
tecnologia do Database.
Estratégia de Redução: Realizar testes, acompanhar o Uptime do servidor. Elaborar
redundância em outro servidor, preferencialmente localizado em local diferente do
servidor principal, utilizando técnicas de espelhamento.
Plano de Contingência: Caso a redundância não assuma automaticamente, verificar a
falha e prover o seu funcionamento recuperando os Backups e informações do
espelhamento.
Pessoa Responsável: Anselmo Júnior
Quadro 10 - Risco 4 - Mudança dos requisitos
Risco: Mudança dos requisitos
Descrição: No decorrer do projeto os requisitos sofreram alterações ou foram
completamente modificados, trocados ou excluídos.
Estratégia de Redução: Analisar bem as expectativas para o produto final e listar
todos os requisitos necessários para que o objetivo seja alcançado.
Plano de Contingência: Estudar os impactos das alterações, elencar prioridades e
redistribuir os membros da equipe para minimizá-los.
Pessoa Responsável: Francyelle Mascarenhas
17

Quadro 11 - Risco 5 - Confusão no levantamento de requisitos
Risco: Confusão no levantamento de requisitos
Descrição: Dúvidas ao elaborar os requisitos.
Estratégia de Redução: Conversar com os stakeholders para sanar todas as dúvidas.
Plano de Contingência: Promover ações para que a dúvida seja completamente
sanada, como elaboração de protótipos, uso de Design Thinking ou outras
metodologias.
Quadro 12 - Risco 6 - Cliente não participa dos reviews
Risco: Cliente não participa dos reviews
Descrição: Mesmo sendo chamado, o cliente não participa das reuniões de review.
Estratégia de Redução: Transmitir ao cliente a importância de que ele participe das
reuniões e documentar os convites da participação do cliente.
Plano de Contingência: Informar por email sobre a ausência do cliente. Sugerir que o
cliente envie pessoas de confiança que conheçam o escopo do projeto para participar
das reuniões.
18

Quadro 13 - Risco 7 - Má execução dos requisitos
Risco: Má execução dos requisitos
Descrição: Os requisitos não estão desenvolvidos segundo a documentação.
Estratégia de Redução: Acompanhar sempre o andamento do projeto para detectar
estas situações prematuramente, caso ocorram.
Plano de Contingência: Analisar os impactos causados e readequar para que os
requisitos sejam cumpridos
Pessoa Responsável: Anselmo Junior
Quadro 14 - Risco 8 - Mal relacionamento com o cliente
Risco: Mal relacionamento com o cliente
Descrição: Membros da equipe entrarem em atrito com o cliente.
Estratégia de Redução: Manter sempre um diálogo profissional e transparente com o
cliente.
Plano de Contingência: Verificar as causas dessa má relação e saná-las
19

Quadro 15 - Risco 9 - Não aplicação do fluxo de processo definido
Risco: Não aplicação do fluxo de processo definido
Descrição: O fluxo das etapas definidas inicialmente foi ignorado durante o projeto.
Estratégia de Redução: Elaborar um fluxo real que condiz com o tamanho do projeto,
equipe e tempo disponível.
Plano de Contingência: Verificar as causas e caso necessário redefinir o fluxo de
processos.
Quadro 16 - Risco 10 - Atraso devido à equipe trabalhar meio período
Risco: Atraso devido a equipe trabalhar meio período
Código: 010 Probabilidade: 55% Impacto: Marginal
Descrição: Devido a equipe trabalhar meio período, o projeto sofrerá um atraso.
Estratégia de Redução: Dada a mão de obra e tamanho do projeto, estimar prazos que
condizentes com a equipe.
Plano de Contingência: Modular a entrega em incrementos definindo prioridades
para que o atraso seja sanado ou minimizado.
20

Quadro 17 - Risco 11 - Comprometimento da equipe
Risco: Comprometimento da equipe
Descrição: O comprometimento da equipe reduz com o passar do tempo.
Estratégia de Redução: Estimular sempre a alta produtividade dos colaboradores e
estar aberto para receber sugestões e críticas.
Plano de Contingência: Conversar individualmente, ou coletivamente, explicar a
situação e sugerir soluções.
Quadro 18 - Risco 12 - Número de Cliente que usarão o projeto
Risco: Número de Cliente que usarão o projeto
Descrição: O número de cliente é superior a estimativa inicial.
Estratégia de Redução: Elaborar uma arquitetura escalável, para que caso haja um
número de acessos maior que o previsto, o sistema não seja comprometido.
Plano de Contingência: Realocar serviços e refatorar áreas que sejam
comprometidas.
21

4.0 Planejamento Temporal
Nesta seção de planejamento temporal iremos abordar as tarefas e suas dependências no Projeto
de Software. O planejamento temporal é fundamental pois possibilita uma boa base para o
gerenciamento do desenvolvimento do software. Devido a isto, Sommerville (2010), recomenda
que o plano seja elaborado no início do projeto. O objetivo é identicar as tarefas, designar o
responsável pela mesma, fornecer uma visão do progresso do projeto. Assim, pode ser usado
tanto pelo cliente como pela equipe de desenvolvimento.
4.1 Conjunto de Tarefas do Projeto
As tarefas denidas e o tempo estimado para realizar o processo de desenvolvimento do
projeto estão no quadro a seguir, Quadro 19. A denição do tempo estimado para
realização das atividades foi de 210 dias úteis e distribuído com base na regra 43-20-37.
Foi definido 40% do esforço do projeto para a atividade de Análise, desenho e
Especicação de Requisitos, 20% destinado a Codicação do software, 37% para a
realização de Testes e 3% para o Planejamento. Visando usar uma metodologia que
permitisse um desenvolvimento iterativo e incremental do produto utilizamos a
metodologia Scrum (aliada a conceitos da metodologia Kanban, pois a ferramenta Trello
é baseada nesta metodologia e nos auxiliou na organização das tarefas).
Quadro 19 - Tempo estimado em cada tarefa
Tarefas Porcentagem (%) Dias de Trabalho
Planejamento 3 6,3
Requisito-Análise-Desenh
o
40 84
Codificação 20 42
Testes 37 77,7
Total 210
Fonte: Autores
22

4.2 Diagrama de Gantt
A Figura 3 mostra as tarefas a serem realizadas de acordo com as datas previstas por
meio do diagrama de Gantt
Figura 3 - Diagrama de Gantt
5.0 Organização da Equipe
Para desenvolver um trabalho em grupo de forma eficiente, é fundamental que as funções, papéis
e responsabilidades de cada um fiquem estabelecidos de forma clara e transparente. Nesta seção,
apresentaremos a função de cada pessoa envolvida no projeto.
5.1 Estrutura da Equipe
A equipe é composta por três pessoas: Anselmo Rodrigues, Francyelle Mascarenhas e
Michael Mendonça. No Quadro 20, a seguir, é mostrado o papel de cada integrante da
equipe.
23

Quadro 20 - Integrantes da equipe e suas funções
Integrante Papel Descrição
Michael Mendonça Gerente de Projeto Planejar e controlar a execução do
projeto; definir papéis e funções da
equipe; Alocar recursos e ajuste de
prioridades; Acompanhar as
atividades dos envolvidos no
projeto.
Anselmo Rodrigues/
Francyelle Mascarenhas/
Michael Mendonça
Analista de Sistemas Mapear processos, modelar dados,
levantar requisitos e regras de
negócio, elaborar diagramas.
Analisar e desenvolver o sistema.
Francyelle Mascarenhas Administração do
Banco de Dados
Modelar, configurar, monitorar o
Banco de Dados.
Francyelle Mascarenhas/
Michael Mendonça
Desenvolvedor Implementar o produto, codificar ou
realizar manutenções nas rotinas do
sistema.
Anselmo Rodrigues Analista de Testes Definir testes necessários, executar
os casos de teste, verificar o
funcionamento do software
identificando e registrando as falhas
e como elas ocorrem.
Fonte: Autores
5.2 Mecanismos de Comunicação
Os mecanismos para a comunicação neste projeto foram:
● Trello: ferramenta que permite o gerenciamento de projetos em lista, capaz de se
adequar às necessidades do usuário, que auxilia na divisão e organização das
tarefas;
24

● Whatsapp: aplicativo de mensagens instantânea que permite a comunicação de
forma ágil entre os componentes da equipe;
● Google Drive: ferramenta colaborativa que facilita a produção de documentos,
bem como a troca destes.
5.3 Uso do Edu-blog como ferramenta de apoio
O edu-blog permitiu a troca de conhecimento entre as equipes da disciplina,
proporcionando um aprendizado diferenciado, interessante e de perspectivas diferentes, já
que um assunto foi tratado pelos diferentes integrantes de uma equipe. Isto agrega um
maior valor ao conhecimento adquirido.
O edu-blog proporcionou também a oportunidade de pesquisarmos e nos aprofundarmos
mais sobre nosso assunto, Plataformas em Nuvem, e como pode ser aplicado no processo
de gerenciamento de projetos, alcançando melhores resultados quanto a questões de
custo/benefício e para agilizar processos no desenvolvimento.
6.0 Precauções tomadas para assegurar e controlar a qualidade do produto de Software
Com o intuito de produzir um projeto de qualidade, foram tomadas algumas precauções.
A primeira delas foi a participação do cliente nas validações de cada etapa do projeto,
desde o levantamento de requisitos até os testes finais. Isto garantiu que o software
produzido realmente atendia as expectativas do cliente.
Uma segunda medida foi a documentação, que serviu para verificar se o que foi realizado
estava de acordo com o que foi especificado. Além de facilitar o entendimento do projeto
no caso de futuras pessoas se associarem ao projeto.
Outra medida foi a realização de testes durante todo o processo de desenvolvimento, com
o intuito de minimizar os erros e garantir um bom funcionamento e comportamento do
software.
Outro ponto chave foi a reunião da equipe de forma periódica. Isto possibilitou o
desenvolvimento de um projeto transparente para a equipe, tanto sobre o que se estava
fazendo, como também quais os problemas encontrados. Assim novas ideias surgiram e
problemas foram resolvidos de forma mais eficaz.
25

7.0 Referências
ISOTANI, S.; ROCHA, R.; Gestão de Riscos em Projetos de Software. Disponível em
<https://edisciplinas.usp.br/pluginfile.php/3385127/mod_resource/content/1/Aula10-GerenciaP
rojeto-Riscos.pdf>. Acessado em 15 de Fevereiro de 2018.
LORENZ, M.; KIDD, J. Object-oriented software metrics: a practical guide. Prentice-Hall, Inc.,
Upper Saddle River, NJ, USA, 1994.
OLIVEIRA, J.; Métricas Para Avaliação Do Grau De Quantificação De Sistemas Orientados Por
Aspecto. Disponível em <http://homepages.dcc.ufmg.br/~mtov/diss/2010_jaqueline.pdf>.
Acessado em 15 de Fevereiro de 2018.
PRESSMAN, R. Software Engineering: A Practitioner’s Approach. 6. ed. New York, NY, USA:
McGraw-Hill, Inc., 2005.
SAMPAIO. Casos de Uso: Diagrama de Casos de Uso. Disponível em
<http://www.dsc.ufcg.edu.br/~sampaio/cursos/2007.1/Graduacao/SI-II/Uml/diagramas/usecase
s/usecases.htm>. Acessado em 15 de Fevereiro de 2018.
SOMMERVILLE, I. Software Engineering (9th Edition). [S.l.]: Pearson, 2010. ISBN
0137035152.
26

Modelo plano projeto de sw oo

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Modelo plano projeto de sw oo

Semelhante a Modelo plano projeto de sw oo (20)

Modelo plano projeto de sw oo