Plano de projeto - Sistema de Remoção de Servidores

UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Programa de Pós-Graduação em Ciência da Computação
Engenharia de Software 2014.1
PLANO DE PROJETO DE SOFTWARE OO
para produtos da Lacertae SW
Diego Armando de Oliveira Meneses – 201411005115
Jislane Silva Santos Menezes – 201411006248
Thiago Couto de Almeida – 201411004833
São Cristóvão
2014
1

UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Programa de Pós-Graduação em Ciência da Computação
Engenharia de Software 2014.1
PLANO DE PROJETO DE SOFTWARE OO
para produtos da Lacertae SW
Diego Armando de Oliveira Meneses – 201411005115
Jislane Silva Santos Menezes – 201411006248
Thiago Couto de Almeida – 201411004833
Trabalho realizado no módulo
de Gestão de Projetos ministrado
pelo Prof. Dr. Rogério Patrício
Chagas do Nascimento na
disciplina de Engenharia de
Software da Pós-Graduação em
Ciência da Computação da
Universidade Federal de Sergipe
(UFS).
São Cristóvão
2014
2

SUMÁRIO
1 INTRODUÇÃO .................................................................................................................... 6
1.1 Âmbito do projeto ..................................................................................................... 6
1.2 Funções principais do produto d software ............................................................. 6
1.3 Requisitos comportamentais ou de performance .................................................. 8
1.4 Gestão e restrições técnicas...................................................................................... 8
2 ESTIMATIVA DO PROJETO............................................................................................ 9
2.1 Dados históricos utilizados para a estimativas....................................................... 9
2.2 Técnicas de estimativa e resultados......................................................................... 9
2.3 Resultados................................................................................................................ 10
2.4 Recurso do projeto.................................................................................................. 11
2.4.1 Recursos humanos ...................................................................................... 11
2.4.2 Recursos de software .................................................................................. 11
2.4.3 Recursos de hardware ............................................................................... 12
3 ANÁLISE E GESTÃO DE RISCOS ................................................................................. 13
3.1 Riscos do projeto...................................................................................................... 13
3.2 Tabela de riscos........................................................................................................ 14
3.3 Redução e gestão de riscos...................................................................................... 17
4 PLANEJAMENTO TEMPORAL..................................................................................... 22
4.1 Conjunto de tarefas do projeto ............................................................................. 22
4.2 Diagrama de Gantt ................................................................................................. 22
5 ORGANIZAÇÃO PESSOAL ............................................................................................ 26
5.1 Estrutura da equipe ................................................................................................ 26
5.2 Mecanismos de comunicação ................................................................................. 26
5.3 Uso do Edu-blog como ferramenta de apoio ........................................................ 26
6 PRECAUÇÕES TOMADAS PARAASSEGURAR E CONTROLAR A QUALIDADE DO
PRODUTO DE SW...................................................................................................... 27
7 REFERÊNCIAS ................................................................................................................. 28
SUMÁRIO DAS FIGURAS
Figura 1: Diagrama de Caso de Uso ............................................................................................. 7
Figura 2: Cronograma Resumido do Projeto (Diagrama de Gantt) ......................................... 23
Figura 3: Cronograma Detalhado do Projeto (Diagrama de Gantt) ………………………..... 24
Figura 4: Diagrama de Gantt do Projeto………………………………………………………. 25
Figura 5: Diagrama de Gantt do Projeto - Continuação……………………………………… 25
3

SUMÁRIO DAS TABELAS
Tabela 1: Descrição do Problema ................................................................................................... 6
Tabela 2: Escopo Geral .................................................................................................................... 6
Tabela 3: Descrição Detalhada do Caso de Uso ............................................................................. 7
Tabela 4: Fatores Multiplicativos para Obter o Número de Classes de Suporte ..................... 10
Tabela 5: Riscos Gerais do Projeto .............................................................................................. 14
Tabela 6: Categorização dos Riscos do Projeto ........................................................................... 15
Tabela 7: Distribuição em dias das fases do projeto ................................................................... 22
5

1 INTRODUÇÃO
1.1 Âmbito do Projeto
O sistema de remoção de servidores é um software para gerenciamento de remoção interna
de funcionários de uma determinada instituição pública X1
de ensino. O objetivo principal deste
software é construir uma fila de espera por cargo, baseada em critérios definidos pela administração.
Desta forma, cada servidor poderá manifestar sua intenção de ser removido para outra localidade
(campus da instituição no estado), possibilitando que a administração possa realocar seus
funcionários de maneira célere e transparente. A Tabela 1 descreve de forma sucinta o problema que
o sistema propõe: o problema, os usuários afetados e o funcionamento ideal. A Tabela 2 exibe quais
são as entradas, o processamento e saída que serão utilizadas pelo software.
Problema
- Gerenciar as remoções internas dos servidores entre os campus da instituição.
- Falta de transparência e celeridade do processo de remoção.
- Burocracia e complexidade para manifestar interesse em remoção.
Usuários
Afetados
- Servidores Ativos (Docentes e técnicos administrativos).
Funcionamento
Ideal
- Melhor gerenciamento das filas de espera.
- Maior transparência e celeridade ao processo de remoção.
- Simplificação do processo de pedido de remoção.
Tabela - Descrição do Problema
Entrada
- Inserção de vagas.
- Manifestação do pedido de interesse.
Processamento
- Ordenação da fila de espera com base nos critérios definidos.
- Informar ao servidor (prioritário) a possibilidade de remoção.
- Confirmação do interesse do servidor em ser removido.
- Confirmação da administração do pedido da remoção.
Saída - A remoção efetiva em um processo transparente e célere.
Tabela - Escopo Geral
1.2 Funções Principais do Produto de Software
Segundo LIMA (2013), as funcionalidades a serem executadas pelo sistema, a fim de
atender aos requisitos do cliente, podem ser expressas através de casos de uso. Um caso de uso é
1 O termo “X” é empregado para manter o sigilo da instituição de ensino.
6

representado por uma elipse conectada a símbolos de atores, bonecos palito. Um ator representa o
papel executado por uma entidade que envia ou recebe informações. Na Figura 1, o diagrama de
caso de uso descreve de forma visual os principais usuários e funcionalidades do software.
A Tabela 3 descreve de forma sucinta as funcionalidades expressas de forma gráfica nos
casos de uso da Figura 1 e seus respectivos atores.
Atores Funcionalidades
Administração
(Especialização do
ator servidor)
- Manter configurações do software (Inserção, Exclusão, Alteração e Consulta).
- Manter edital de remoção (Inserção, Exclusão, Alteração e Consulta).
- Manter vaga de remoção (Inserção, Exclusão, Alteração e Consulta).
- Confirmação da remoção perante conformidade aos critérios estabelecidos.
Servidor - Consultar fila de interesses cadastradas (fila de interesse ordenada de acordo
com os critérios informados pela administração).
- Manter interesse na remoção (Inserção, Exclusão, Alteração e Consulta).
- Consultar vagas de remoção cadastradas.
- Confirmar interesse de remoção solicitada.
Tabela - Descrição detalhada do caso de uso
1.3 Requisitos Comportamentais ou de Performance
A seguir serão listados os requisitos comportamentais ou de performance do Sistema de
Remoção:
• Reduzir a probabilidade de indisponibilidade do acesso ao sistema;
• Minimizar a probabilidade de corrupção de dados;
• Observação dos padrões e regras estabelecidas garantindo a transparência e corretude do processo;
• Segurança de acesso, permitindo acesso somente aos servidores habilitados;
• Facilidade para operar o produto;
• Minimizar o esforço para realizar alterações, remover falhas e/ou adequar o produto a eventuais
mudanças de ambiente.
1.4 Gestão e Restrições Técnicas
A seguir serão listadas algumas restrições técnicas do Sistema de Remoção:
• O sistema necessita ser desenvolvido utilizando arquitetura web.
• O sistema necessita ser desenvolvido utilizando a linguagem JAVA utilizando o framework JSF.
• O sistema deve utilizar o PostgreSQL como banco de dados.
• O sistema deve utilizar o Subversion como controlador de versão.
• O acesso ao sistema deve ser feito por um navegador web.
7
Figura - Diagrama de caso de uso

2 ESTIMATIVA DO PROJETO
Segundo PRESSMAN(2006), o cálculo das estimativas é uma das atividades fundamentais
do processo de gerenciamento de projetos de software. Nesta etapa é realizado o planejamento do
esforço humano, o custo e da duração cronológica do projeto. Estimativas são baseadas em métricas
históricas e empíricas.
Os objetivos de utilização das métricas e estimativas são:
● Entender o comportamento e funcionamento do produto de software;
● Avaliar os padrões, metas e critérios de aceitação;
● Controlar processos produtos e serviços;
● Prever valores de atributos
O uso correto das métricas e estimativas traz alguns benefícios, como:
● Indicar qualidade do produto;
● Formar base de dados para outros projetos;
● Avaliar produtividade;
● Ajudar na tomada de decisões estratégicas.
2.1 Dados Históricos Utilizados para as Estimativas
A instituição X que executará o projeto não possui um histórico de elaboração de produtos
de software. Não sendo possível estabelecer comparações e estimativas baseadas em um histórico.
2.2 Técnicas de Estimativa e Resultado
Nesta subseção demonstra-se como foi efetuado o cálculo para estimar a duração do projeto
(em dias). Para aferir esse esforço utilizou-se a métrica de Lorenz & Kidd (1994). A métrica de
Lorenz & Kidd é composta dos passos descritos a seguir:
1. Definir o número de classes chave.
2. Encontrar o número de classes de suporte - é necessário classificar o tipo da interface do
produto e desenvolver um multiplicador para as classes de suporte (a Tabela 4 apresenta uma lista
de multiplicadores de acordo com o tipo de interface da aplicação a ser estimada).
3. Multiplicar a quantidade de classes chave pelo multiplicador obtendo uma estimativa do
número de classes de suporte.
4. Calcular a quantidade total de classes, somando o número de classes chave com o número
de classes de suporte.
9

5. Multiplicar a quantidade total de classes (obtidas no item anterior) pelo número médio de
unidades de trabalho (dias - pessoa) por classe. A métrica sugere entre 15 e 20 dias.
6. Determinar a quantidade de esforço estimada.
7. Calcular o tempo previsto para a elaboração do projeto.
Interface Multiplicador
Não gráfica 2
Baseada em textos 2,25
GUI 2,5
GUI complexa 3
Tabela - Fatores multiplicativos para obter o número de classes de suporte
2.3 Resultados
Utilizando a métrica de Lorenz e Kidd (1994) descrita na sub-seção anterior, obtém-se os
seguintes valores:
1. Número de Classes Principais:
4 classes: Servidor, Vaga, Interesse e Configurações.
2. Definição do multiplicador:
Como a interface fora classificada como GUI, temos como 2,5 fator multiplicador
(ver Tabela 4).
3. Número de classes de suporte:
Nº Classes chave X multiplicador = 4 X 2.5 = 10 classes de suporte.
4. Número total de classes:
Nº Classes Chave + Nº Classes de Suporte = 4 + 10 = 14 classes.
5. Definição do número médio de unidades de trabalho:
Definiu-se que a unidade de trabalho será de 20 dias-pessoa já que não há um
histórico para realização de estimativas.
6. Determinação da quantidade de esforço estimada.
Nº Total de Classes X Unidades de trabalho = 14 X 20 = 280 dias.
7. Cálculo do tempo previsto para a elaboração do projeto.
Primeiro obtemos a quantidade de dias corridos através do seguinte cálculo:
10

Dias corridos = Dias estimados X (dias por mês / dias úteis por mês). Dessa forma,
temos:
Dias corridos = 280 X (30/22) = 8400/22 = 381,81 = 382.
Como teremos 3 pessoas envolvidas em todas as fases do projeto podemos dividir o
número total de dias pela quantidade de pessoas envolvidas.
Dias = 382 / 3 = 127,33 = 128 dias
Tomando por base que o projeto será construído utilizando a metodologia de
desenvolvimento iterativo e incremental e que o projeto será executado em dois ciclos,
definiu-se que para o primeiro ciclo serão necessários 78 dias e no segundo ciclo será
produzido em 50 dias. O primeiro ciclo é mais extenso que o outro, já que as tarefas mais
importantes do sistema se encontram nesta fase.
.
2.4 Recursos de Projeto
Os recursos de projeto são elementos importantes para o planejamento e execução. O projeto
de software utiliza recursos materiais (equipamentos e programas) e recursos humanos. O
gerenciamento desses recursos promove uma utilização mais efetiva durante o andamento do
projeto.
2.4.1 Gestão de Pessoas
A gestão de pessoas envolve processos como identificação, atribuição de funções,
responsabilidades, desenvolvimento e gerenciamento da equipe do projeto (DINSMORE;
CAVALIERI,2008).
No projeto Remoção, a equipe é composta por três membros que estão envolvidos em todas
as fases do projeto. As funções executadas pelos membros serão detalhadas na subseção 5.1.
A equipe é composta por três membros que estão envolvidos em todas as fases do projeto.
As funções executadas pelos membros serão detalhadas na subseção 5.1.
2.4.2 Recursos de Software
Os recursos de software utilizados no projeto são ferramentas de conhecimento público,
amplamente utilizadas na comunidade, nenhum deles requer uma licença específica para sua
utilização. São eles:
● Subversion (controlador de versão)
11

● TortoiseSVN-1.8.5.25224-x64-svn-1.8.8 (cliente do Subversion)
● Apache/Tomcat 7.x (servidor de aplicação)
● Star UML 5.0 (ferramenta para elaboração de diagramas UML)
● DBDesigner 4 (ferramenta para elaboração DER)
● jdk-7u51-windows-x64 (máquina virtual JAVA)
● netbeans-7.4-javaee-windows (IDE de desenvolvimento)
● primefaces-4.0 (biblioteca de componentes do JSF)
● primefaces-4.0-sources (sources do Prime Faces)
● PostgreSQL 8.4 (Banco de dados)
● pgAdmin (cliente do PostgreSQL)
● postgresql-9.1.11-2-windows-x64 (driver para acesso ao banco de dados)
● OpenProj - 1.4 (ferramenta para elaboração do gráfico de Gantt)
2.4.3 Recursos de Hardware
Os recursos de hardware exigidos pela aplicação são amplamente atendidos pela instituição.
● Computadores pessoais para cada membro da equipe em rede local;
● Servidor de desenvolvimento virtualizado;
● Servidor de treinamento virtualizado;
● Servidor de produção virtualizado.
12

3 ANÁLISE E GESTÃO DE RISCOS
Os riscos são problemas em potencial que podem ou não, vir a se concretizar. Em
PRESSMAN (2006) encontramos três fundamentos conceituais que definem o risco: o futuro, as
modificações e que métodos e ferramentas devem ser utilizados. O futuro é imprevisível, assim é
difícil prever que riscos podem causar o insucesso do projeto de software. As modificações nos
requisitos, ou em outros aspectos relacionados ao projeto como tecnologia de desenvolvimento e
suporte podem resultar em atrasos de cronograma e por conseguinte o insucesso do projeto. Quanto
aos métodos e ferramentas, que procedimentos de qualidade devem ser aplicados durante o projeto.
A fim de minimizar os riscos, é necessário gerenciá-los. Segundo o PMBOK(2008), o
gerenciamento de riscos do projeto inclui os processos relacionados com o planejamento,
identificação, análise, elaboração de respostas, monitoramento e controle dos riscos em um projeto.
Esta fase é conhecida por análise e gestão de risco que são ações que auxiliam uma equipe de
software a compreender e gerenciar as incertezas do negócio.
Alguns passos devem ser realizados para gerenciar esses riscos, são eles:
● Identificar os riscos
● Avaliar probabilidade de ocorrência
● Estimar o impacto
● Estabelecer o plano de contingência
Os três primeiros passos resultam na tabela dos riscos do projeto, abordados na seção 3.2. O
plano de contingência será abordado na seção 3.3.
Os envolvidos nesta etapa são todos aqueles que fazem parte da gestão de qualidade do
produto (Gerentes, Engenheiros de Software, Stakeholders). É importante a utilização da gestão de
riscos, pois alguns riscos, se concretizados podem vir a suspender o processo de produção do
produto (PRESSMAN,2006).
3.1 Riscos do Projeto
Alguns riscos estão sempre presentes em quaisquer projeto de software, eles podem ser
considerados riscos gerais e são listados na Tabela 5.
Risco Projeto Técnico Negócio Comum Especial
13

Equipamento não disponível X
Requisitos incompletos X X
Uso de metodologias especiais X X
Problemas na busca da confiabilidade
requerida
X X
Retenção de pessoas chaves X X
Subestimativas de esforço X X
Tabela - Riscos gerais do projeto
Avaliação Global do Risco:
1. O Gestor de Software dá suporte ao projeto?
Sim. O gestor estará responsável por garantir o alcance do sucesso do produto de software,
participando e informando aos interessados sobre o andamento do projeto.
2. Os Clientes estão entusiasmados com o produto?
Sim. Pois a implantação do produto trará transparência e publicidade ao processo de seleção
dos concursos de remoção interna.
3. Os Engenheiros de Software compreenderam bem os requisitos?
Sim. Os engenheiros tem acesso aos requisitos legais (critérios definidos pela gestão do
órgão) que determinam os parâmetros que influenciam na seleção.
4. Os Clientes estiveram envolvidos na definição dos requisitos?
Sim. Os clientes expuseram de maneira formal quais os principais requisitos necessários
para construir a aplicação.
5. O âmbito do projeto é estável?
Não. O escopo do projeto é variável já que os requisitos legais podem ser alterados.
6. Os engenheiros de Software têm as competências requeridas?
Sim. Os gerentes são qualificados para as atividades que lhes são propostas.
7. Os requisitos do projeto são estáveis?
14

Não. Como o instituto tem autoridade para reger os critérios de seleção para remoção
interna, a influência da gestão é quem garante a estabilidade.
8. A Equipe de Desenvolvimento tem experiência na tecnologia que será utilizada?
Sim. A equipe de desenvolvimento possui experiência acadêmica nas tecnologias que estão
sendo utilizadas.
9. É adequado o número de pessoas da equipe de trabalho?
Não é possível prever este quesito já que não há um histórico de desenvolvimento de
projetos pela equipe.
3.2 Tabela de Riscos
A tabela de riscos contém os riscos identificados no projeto, dispostos em ordem decrescente
de probabilidade e impacto (PRESSMAN,2006). A Tabela 6 identifica para cada risco a sua
categoria, probabilidade de ocorrência e impacto sobre o projeto em caso de concretização do risco.
Foram identificados 20 riscos em diferentes categorias.
Nº Risco Categoria Probabilidade Impacto
1 Iminência de greve
Pessoal 85% Crítico
2 Influência de restrições governamentais
associada à legislação que define o negócio
Negócio 80% Catastrófico
3 Requisitos instáveis do projeto
Negócio 80% Catastrófico
4 Uso de novas tecnologias
Tecnologia 80% Crítico
5 Escopo instável do projeto
Tamanho 75% Catastrófico
6
Alta visibilidade (expectativa) do número
de clientes que usarão o produto Negócio 75% Crítico
7 Não utilização de revisões técnicas formais
Processo 75% Crítico
15

8 Descomprometimento da alta
administração com o desenvolvimento do
projeto Negócio 60% Crítico
9 Prazos e tempo para tarefas mal estimados
- risco de projeto Negócio 60% Crítico
10 Restrições de interoperabilidade com o
sistema de RH Negócio 50% Catastrófico
11 Falta de experiência da equipe na
tecnologia
Pessoal 50% Marginal
12 Mau uso das ferramentas de auxílio a
construção do software Ambiente 35% Marginal
13 Imprevistos de pessoal
Pessoal 30% Crítico
14 Uso incorreto de ferramentas CASE para
análise, design e teste
Processo 20% Crítico
15 Número de usuário do produto
(crescimento do número de usuários)
Tamanho 20% Marginal
16 Porcentagem de crescimento da base de
dados Tamanho 20% Marginal
17 Impactos no orçamento da empresa
Instituição Pública Negócio 15% Crítico
18 Volatilidade do pessoal da equipe Pessoal 15% Crítico
19 Colaboradores do projeto são também
clientes do produto Pessoal 15% Marginal
20 Descontinuação de ferramentas de auxílio a
construção de software
Ambiente 10% Desprezível
16

Tabela - Tabela de Riscos e Categorização dos Riscos do Projeto
3.3 Redução e gestão de riscos
O Plano de Redução, supervisão e gestão do risco (RSGR) é desenvolvido para ser utilizado
quando um risco de fato se concretiza, ou seja, quando os planos de prevenção ao risco falharam ou
quando os riscos tem probabilidade eminente de acontecer.
Para identificar quais os riscos que terão o plano de contingência (RSGR) estabelecido,
utilizou-se a métrica Categoria/Probabilidade, onde o ponto de corte é: riscos com categoria
(Catastrófico e Crítico) igual ou acima de 50% de probabilidade de ocorrência (Os riscos que se
aplicam a essa métrica foram destacados em vermelho na tabela de riscos).
Greve
Risco 1 Probabilidade: 85% Impacto: Crítico
Descrição: Iminência de greve dos servidores ativos da instituição pública (Docentes e/ou
técnicos administrativos) durante todo ou parte do período estabelecido para o projeto. Obs: esse
risco foi classificado com uma alta probabilidade porque na instituição de ensino que usamos
como escopo há uma indicação muito forte de greve, onde essa indicação será aprovada ou não no
dia 29/04. http://www.sinasefe.org.br/v3/index.php/noticias-da-greve/991-greve-do-sinasefe-comeca-hoje
Estratégia de redução: Não existe estratégia de redução. As greves em instituições públicas onde
seus servidores ativos trabalham sobre um regime estatutário estão fora do escopo da gerência de
projetos, ou seja, o gerente de projetos não tem competência sobre essa decisão.
Plano de contingência: Alterar o cronograma e renegociar o prazo de entrega do produto.
Contratar equipe terceirizada que não faça parte dos servidores ativos.
Pessoa responsável: Thiago Couto de Almeida (criação 16/04/2014)
Status: Situação completada (22/04/2014)
Influência de restrições governamentais associada à legislação que define o negócio
Risco 2 Probabilidade: 80% Impacto: Catastrófico
Descrição: Critérios que norteiam a remoção dos servidores podem ser criados e alterados através
de normativas do Ministério do Planejamento, Orçamento e Gestão (MPOG), tirando a autonomia
do instituto em estabelecer critérios próprios para ordenar a fila de interesses.
Estratégia de redução: Avaliação da legislação no que se refere a remoção de servidores na
17

administração pública.
Plano de contingência: Reavaliar requisitos funcionais do projeto. Negociar novos prazos.
Requisitos instáveis do projeto
Descrição: Requisitos do projeto instável. As mudanças de requisitos durante o desenvolvimento
do projeto podem impactar significativamente o andamento do mesmo, podendo levar até a
suspenção do projeto.
Estratégia de redução: Proporcionar reuniões periódicas de conscientização dos benefícios da
implantação do produto de software.
Plano de contingência: Realizar a redefinição do escopo, alterar o cronograma e renegociar o
prazo de entrega do produto.
Uso de novas tecnologias
Descrição: A equipe do projeto não possui experiência nas tecnologias usadas para análise,
projeto e desenvolvimento do produto de software, essa falta de conhecimento pode acarretar em
atrasos no cronograma, isso acontece por causa do tempo estendido para se realizar as tarefas nas
novas ferramentas (Curva de aprendizado muito grande).
Estratégia de redução: Treinar a equipe de desenvolvimento nas novas tecnologias antes de
iniciar o projeto.
Plano de contingência: Alterar o cronograma e renegociar o prazo de entrega do produto.
Escopo instável do projeto
18

Descrição: Escopo do projeto instável
Estratégia de redução: A instabilidade do escopo depende da alteração dos critérios de remoção,
assim estas configurações devem ser parametrizadas de forma que o produto seja pouco
modificado. Na ocorrência de alteração do escopo a estratégia é dividir as entregas do projeto.
Plano de contingência: Realizar a revisão do escopo e entregar módulos parciais do produto;
atualizar cronograma.
Alta visibilidade (expectativa) do número de clientes que usarão o produto
Descrição: Este software terá como usuários uma grande parte dos servidores da instituição que
aguardam durante anos a oportunidade de concorrerem em um edital de remoção.
Estratégia: Cumprir as metas estabelecidas no plano de projeto de software para que os prazos
sejam obedecidos.
Plano de contingência: Reestabelecer novos prazos, e esclarecer aos usuários o porquê não foi
possível entregar o software no prazos determinado.
Não utilização de revisões técnicas formais
Descrição: A não utilização de revisões técnicas formais torna o software final sem qualidade,
pois com a ausência dessa técnica não se consegue: descobrir erros de funções ou lógica, avaliar
se o software esta em conformidade com os requisitos, garantir o uso dos padrões pré-definidos,
uniformidade do software, apontar melhorias necessárias. A não utilização de revisões formais é
causada pela falta de experiência da equipe em projetos de software gerenciados.
Estratégia: Fazer um plano para utilização de revisões técnicas consolidadas no projeto.
Plano de contingência: Revisar o projeto identificando as áreas afetadas e corrigindo os
problemas com o uso adequado das revisões técnicas.
19

Status: Situação completada (2204/2014)
Descomprometimento da alta administração com o desenvolvimento do projeto
Descrição: Descomprometimento da alta administração com o desenvolvimento do projeto
Estratégia de redução: Integrar os stakeholders nas etapas de desenvolvimento do projeto
Plano de contingência: Proporcionar reuniões periódicas de conscientização dos benefícios da
implantação do produto de software; Gerenciar as expectativas dos interessados no projeto
Prazos e tempo para tarefas mal estimados
Descrição: Prazos e tempo para tarefas mal estimados
Estratégia de redução: Utilizar técnica do valor agregado para avaliar a condução do projeto.
Realizar reuniões periódicas de acompanhamento de status do projeto
Plano de contingência: Revisar escopo, atualizar cronograma e redistribuir as tarefas para a
equipe sempre que necessário
Restrições de interoperabilidade com o sistema de RH
Descrição: Os dados dos servidores são consultados no sistema de RH, se não existir a
interoperabilidade a principal fonte de dados não será acessível.
Estratégia: Notificar a empresa contratada responsável pelo sistema de RH, que qualquer
20

alteração que for ser realizada deverá ser informada com antecedência mínima de 15 dias e que a
mesma entregue a documentação da alteração realizada.
Plano de contingência: Alocar os esforços da equipe para reconstruir a integração entre os
softwares.
21

4. PLANEJAMENTO TEMPORAL
Etapa responsável pelo planejamento temporal das atividades definindo as datas de
execução das tarefas e os papéis responsáveis pela execução.
4.1 Conjunto de Tarefas do Projeto
A metodologia utilizada para planejar o projeto é uma implementação do modelo interativo
incremental em conjunto com as fases de processo definidas pela Lacertae SW, acrescentando a este
modelo a fase de implantação e treinamento. Devido ao escopo do projeto e as necessidades de
entrega de releases (versão funcional do software), o projeto foi dividido em 2 ciclos. O primeiro
ciclo, por conter mais atividades importantes demanda um tempo maior. O tempo estimado para o
processo de desenvolvimento do software foi de 382 dias corridos. A equipe destinada para o
projeto possui 3 pessoas. Diante desta configuração a quantidade de dias necessários para realizar o
projeto foi reduzida para 128 dias, divididos em 2 ciclos (1º Ciclo: 78 dias e 2º Ciclo: 50 dias).
A Tabela 7 mostra de forma detalhada a distribuição dos dias para cada fase do processo,
dentro do seu ciclo, cada ciclo é responsável pela entrega de um release. Esta abordagem em 2
ciclos foi planejada por causa da necessidade de avaliar o software em funcionamento com os
usuários reais na primeira entrega.
Fase Porcentagem Duração (dias)
1º Ciclo
Duração (dias)
2º Ciclo
Planejamento 3% 2,34 1,5
Análise e Projeto 38% 29,64 19
Codificação 19% 14,82 9,5
Testes 37% 28,86 18.5
Implantação e Treinamento 3% 2,34 1,5
Tabela - Distribuição em dias das fases do projeto
4.2 Diagrama de Gantt
O Diagrama de Gantt é uma ferramenta que permite através de gráficos informar o
andamento das etapas do projeto. Segundo DINSMORE e CAVALIERI (2008), trata-se de uma
22

relação de atividades do plano de projeto associadas a uma matriz de tempo, onde são marcadas
para cada uma das atividades seu início e término. Sua facilidade de uso, o transformou em uma das
ferramentas mais utilizadas para gerenciar cronogramas de atividade de projeto e seus respectivos
recursos. Dentre os benefícios do seu uso, estão:
● Melhor representação do cronograma (Representação intuitiva)
● Melhor representação das atividades do projeto e seus recursos
● Melhor visualização das dependências entre as atividades
● Boa forma de avaliar os custos de tempo e recursos
Na Figura 2, podemos ver o cronograma resumido das atividades do projeto, nele é
mostrado apenas as etapas mais gerais do projeto e os ciclos que vão ser executados. Também é
possível visualizar os recursos utilizados nas atividades, é importante ressaltar que os envolvidos
participam de todas as etapas e ciclos definidos.
Figura - Cronograma resumido do projeto (Diagrama de Gantt)
Nas Figuras 3, observa-se o cronograma mais detalhado do projeto, onde as atividades mais
especificas de cada fase são exibidas, informado seus dias e recursos necessários, além das
dependências com outras atividades.
23

Figura - Cronograma detalhado do projeto - Diagrama de Gantt
24

Nas Figuras 4 e 5, são demonstradas as etapas do projeto no diagrama de Gantt. O gráfico
corresponde às atividades, recursos e tempo visualizados nas imagens anteriores. Ele permite
visualizar sobreposição entre atividades, fazer marcações entre trabalho planejado e realizado
facilitando o acompanhamento das tarefas do projeto (DINSMORE;CAVALIERI,2008).
Figura 4. Diagrama de Gantt do Projeto
25

Figura 5. Diagrama de Gantt do Projeto - Continuação
26

5. ORGANIZAÇÃO DO PESSOAL
Para uma organização desenvolver um projeto de software é necessário destinar uma equipe
especializada com o contexto do projeto. Esta atividade de indicação é uma tarefa do gerente de
projetos. PRESSMAN (2006) sugere que a montagem da estrutura de uma equipe depende do estilo
de gestão da organização, da quantidade de pessoas que formarão a equipe e seus níveis de aptidão
e da dificuldade geral do problema.
No caso do projeto Remoção Interna a equipe faz parte do setor de informática da instituição
sendo considerado os critérios do estilo de gestão da organização e nível de aptidão da equipe.
5.1 Estrutura da Equipe
Várias atividades do projeto são conhecidas e executadas por todos os membros da equipe.
Neste projeto temos o Gestor do Projeto que é o responsável por planejar, executar, acompanhar as
atividades do projeto e garantir que o processo seja entendido e seguido por todos os envolvidos e
os analistas, responsáveis pela modelagem e implementação dos requisitos do projeto. O projeto
contará com dois analistas.
5.2 Mecanismos de Comunicação
Os mecanismos de comunicação da equipe são utilizados para garantir que as informações
sejam disponibilizadas de forma adequada a todos os interessados no momento oportuno. Entre os
membros da equipe a comunicação pode ser formal ou informal. Os meios para comunicação
formal são documentos escritos e reuniões estruturadas e para a informal uso de e-mails e encontros
pessoais para troca de ideias.
5.3 Uso do Edu-blog como Ferramenta de Apoio
O uso do Edu-blog mostrou-se como uma importante ferramenta de apoio nas atividades de
elaboração do plano de projeto de software, já que, todos os membros podem divulgar suas
atividades de forma clara e acessível, possibilitando que o conhecimento produzido seja
compartilhado e difundido entre os diferentes grupos de trabalhos.
27

6 PRECAUÇÕES TOMADAS PARAASSEGURAR E CONTROLAR A QUALIDADE DO
PRODUTO DE SW
Algumas ações foram definidas para garantir a qualidade do produto de software, são elas:
● realização de testes de unidade;
● realização de testes de integração;
● realização de testes de interface;
● realização de testes de configuração;
● realização periódicas de revisões técnicas.
28

7 REFERÊNCIAS BIBLIOGRÁFICAS
—LIMA, Adilson da Silva. UML, 2.3: do requisito à solução, São Paulo: Érica, 2013.
LORENZ. M, KIDD J., Object-Oriented Software Metrics, Prentice Hall, 1994.
PRESSMAN, Roger S. Engenharia de software. 6ª ed. Porto Alegre: Bookman, 2006.
GUIA PMBOK. Um guia do conjunto de conhecimentos em gerenciamento de projetos. 4ª ed.
Pennsylvania: Project Management Institute, 2008.
DINSMORE,P. C., CAVALIERI, A. Como se tornar um profissional em gerenciamento de projetos.
2a edição. QualityMark, 2008.
29

Plano de projeto - Sistema de Remoção de Servidores

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Similaire à Plano de projeto - Sistema de Remoção de Servidores

Similaire à Plano de projeto - Sistema de Remoção de Servidores (20)

Plano de projeto - Sistema de Remoção de Servidores