Plano de Projeto SGS

UNIVERSIDADE FEDERAL DO AMAZONAS
INSTITUTO DE COMPUTAÇÃO

PLANO DE PROJETO DE SOFTWARE

TÍTULO: SISTEMA DE GERENCIAMENTO DE SERVIÇOS – SGS
VERSÃO 1.0

Equipe:
Rafael do Nascimento Almeida
Rodrigo Azevedo da Costa
Tiago Lahan da Silva

Professor Orientador:
Rogério P. C. do Nascimento

Manaus – AM
2011

Sumário

1. INTRODUÇÃO ....................................................................................................................... 3

1.1 Âmbito do Projeto.......................................................................................................... 3

1.2 Funções principais do produto de software .......................................................... 3

1.3 Requisitos comportamentais ou de performance ................................................ 4

1.4 Gestão e Restrições Técnicas.................................................................................... 4

2. ESTIMAÇÕES DO PROJETO ............................................................................................. 5

2.1 Dados históricos utilizados para as estimativas .................................................. 5

2.2 Técnicas de estimativas e resultados ...................................................................... 5

2.2.1 Técnicas de estimativa ............................................................................................. 5

2.3 Resultados....................................................................................................................... 6

2.4 Recursos do Projeto ..................................................................................................... 7

3. ANÁLISE E GESTÃO DE RISCOS ..................................................................................... 8

3.1 Riscos do Projeto .......................................................................................................... 8

3.2 Tabela de Riscos ........................................................................................................... 9

3.3 Estratégias para Gestão de Riscos ........................................................................ 10

4. PLANEJAMENTO TEMPORAL ......................................................................................... 13

4.1 Conjunto de Tarefas do Projeto ............................................................................... 13

4.2 Diagrama de Gantt....................................................................................................... 13

5. ORGANIZAÇÃO DO PESSOAL ........................................................................................ 14

5.1 Estrutura da equipe..................................................................................................... 14

5.2 Mecanismos de comunicação .................................................................................. 14

5.3 Uso do Edu-blog como ferramenta de apoio ....................................................... 15

Plano de Projeto de Software Página 2

1. INTRODUÇÃO

1.1 Âmbito do Projeto

Atualmente na Universidade Federal do Amazonas - UFAM, as requisições de
serviços são solicitadas por meio de uma requisição em papel, o que muitas vezes
pode causar perda, esquecimento ou até extravio de alguma requisição importante. A
prefeitura então, recebe a requisição, envia para a divisão responsável que executa as
atividades necessárias. Existe um controle das requisições solicitadas mas, sem um
acompanhamento das atividades realizadas por parte do usuário nem controle sobre
os gastos com tais atividades.
Dessa forma, o Sistema de Gestão de Serviços - SGS, visa disponibilizar um
melhor controle estatístico e financeiro dos serviços realizados assim como,
possibilitar o acompanhamento das atividades de um serviço pelo requisitante. O SGS
proporcionará também um controle da requisição desde a sua criação até o seu
arquivamento ou descarte.

1.2 Funções principais do produto de software

O escopo do sistema SGS é composto das principais funções:
• Cadastro de requisições de serviço;
• Consulta eletrônica da situação das atividades do serviço;
• Controle estatístico e financeiro de requisições cadastradas;
• Categorização de acesso de acordo com cada usuário;
• Emissão de relatórios para consulta por: Divisão, Unidade Solicitante, Situação
e Data;

O sistema deve permitir as seguintes funcionalidades para os usuários;

Administrador
o Manter usuários do sistema;
o Gerir requisições;
o Cancelar requisições em andamento;
o Emissão de relatórios estatísticos e financeiros.


Requisitante
o Solicitar requisição;
o Acompanhar as atividades de um serviço;

1.3 Requisitos comportamentais ou de performance

Sobre os requisitos comportamentais, as funcionalidades não são consideradas
críticas, porém, devem atender o máximo possível as funcionalidades já existentes em
versões anteriores ao SGS, pois, a cultural comportamental dos servidores afeta no
desempenho e na utilização do software.
Em termos de performance, o software terá que responder adequadamente a
certos critérios, sendo fundamentais, a interface e a acessibilidade. Dessa forma, é
necessário que a interface seja agradável para o utilizador do sistema. Deve atender a
pessoas que possuem pouco ou nenhum conhecimento em informática ou utilização
de ambiente web.

1.4 Gestão e Restrições Técnicas

Esta seção lista os itens que trazem restrição para o desenvolvimento do
sistema e, delimita o escopo em que o sistema deverá ser produzido.

• O sistema deverá importar a base de dados do SIE.
• O sistema deverá ser construído utilizando a tecnologia Grails.
• Falta de experiência prática com as ferramentas e métodos utilizados para o
desenvolvimento.


2. ESTIMAÇÕES DO PROJETO

Estimativas de projeto são realizadas com o intuito de acompanhar todo o fluxo
de atividades de um determinado projeto de software. Assim, temos uma visão geral
dos prazos e cronogramas a serem obedecidos. As estimações levam em
consideração uma série de fatores tais como: número de pessoas envolvidas,
complexidade do projeto, material disponível para execução das atividades,
conhecimento técnico dos envolvidos entre outros que influenciam diretamente no
sucesso da aplicação.
As estimativas mostram ao gerente de projeto o que tem que ser feito em cada
etapa da longevidade do processo de desenvolvimento, mostrando ainda se o projeto
está em dia, em atraso ou, adiantado. Dessa forma, o gerente pode cobrar resultados
dos responsáveis e, acompanhar de perto cada fase que está sendo realizada,
possuindo embasamento teórico para isso.

2.1 Dados históricos utilizados para as estimativas

É nosso primeiro trabalho de projeto levando em consideração cálculos para
estimativas e, nenhum membro possui experiência em gerência projeto de software.

2.2 Técnicas de estimativas e resultados

Para estimar o prazo total do projeto, foi utilizada a métrica de Lorenz & Kidd
(orientado a classes), apresentada pela Lacertae Software. Aqui, demonstramos o
cálculo realizado e os fatores envolvidos.

2.2.1 Técnicas de estimativa

Utilização da técnica Lorenz & Kidd:
a. Definição do número de Classes-chave;
b. Definição do número de Classes de suporte. Consiste em classificar o tipo de
Interface do Produto e determinar um valor Multiplicador para as Classes de
suporte;
c. Multiplicar a quantidade de Classes-chave pelo valor Multiplicador, obtendo o
número de Classes de suporte;


d. Cálculo da quantidade total de classes (Classes-chave + Classes de suporte);
e. Multiplicar o total de classes pelo número médio de unidades de trabalho (dias-
pessoa);
f. Determinar a quantidade de esforço estimada;
g. Cálculo do tempo previsto para a realização do projeto.

A Tabela 1, abaixo, mostra os fatores de multiplicação utilizados para encontrar
a quantidade de classes de suporte:

Interface Valor multiplicador
Não gráfica 2
Baseada em texto 2,25
GUI 2,5
GUI Complexa 3
Tabela 1. Fator de multiplicação

2.3 Resultados

De acordo com a métrica descrita acima se obteve os seguintes resultados:

1. Número de classes chaves = 10;
2. Sistema em ambiente web. Então, interface gráfica GUI = 2,5;
3. Classes chaves x multiplicador (10 x 2,5) = 25 classes de suporte;
4. Número total de classes: Classes chaves + classes de suporte (10 + 25) = 35;
5. Por falta de experiência da equipe em trabalhos do gênero, consideramos o
máximo de dias indicado pela métrica (20 dias-pessoa);
6. Para calcular a quantidade de esforço estimada: 35 x 20 = 700 dias de
trabalho;

No melhor caso, considerando três pessoas envolvidas no projeto, temos:
700 dias ÷ 3 pessoas = 233,33 dias-pessoa o que dividindo por 30 (dias/mês) resulta
no tempo total de aproximadamente 8 meses. Para este cálculo, utilizou-se a
quantidade total de dias no mês (30) e não apenas os dias úteis (22).


2.4 Recursos do Projeto

2.4.1 Recursos Humanos

O projeto contará com três pessoas que exercerão os diversos papéis
necessários para a execução do projeto de desenvolvimento do software, Na Tabela 2,
abaixo, verificamos os envolvidos de acordo com os seus respectivos papéis.

Papel Responsável
Gerente do Projeto Tiago Lahan
Analista de Sistemas Rafael Almeida
Projetista de Software Rodrigo Azevedo
Codificador Tiago Lahan, Rafael Almeida
Testador Rodrigo Azevedo
Tabela 2. Recursos Humanos

2.4.2 Recursos do ambiente de desenvolvimento

Para o desenvolvimento deste projeto foram utilizados os seguintes recursos
de software:

• Netbeans: Ambiente gráfico que suporta desenvolvimento em Grails;
• Grails: Framework de desenvolvimento
• Groovy: Linguagem de programação com recursos para Web;
• Mysql: Banco de dados free com suporte a múltiplas linguagens;
• MsProject 2010: Ferramenta case que auxilia na gerência das atividades
do projeto;
• Editor de texto Word: Realizar a documentação do projeto;
• Subversion: Ferramenta para controlar as versões de software produzidas.

Para a composição física do projeto, utilizaremos dois microcomputadores em
rede local com todos os recursos de software descritos para o desenvolvimento do
projeto.


3. ANÁLISE E GESTÃO DE RISCOS

Esta etapa consiste em uma série de passos que permitem compreender e
gerir as incertezas que podem ocorrer. Dessa forma, quanto aos riscos, precisamos
identificá-los, avaliar sua probabilidade de ocorrência e estimar o seu impacto no
projeto de software para que possamos estar preparados para administrá-los.

3.1 Riscos do Projeto

Relacionamos os riscos envolvidos no projeto de acordo com a sua categoria.
Na Tabela 3 podemos visualizar esta ligação.

Riscos Projeto Técnico Negócio Comum Especial
Requisitos incompletos x x
Treinamento x
Mudança no cronograma para entrega x x
Rotatividade da equipe x
Mudança da tecnologia adotada x x
Regras de negócio não foram definidas x
Tabela 3. Riscos Gerais do Projeto

Avaliação global dos riscos:

1. O Gerente de software dá suporte ao projeto?
Sim, o gerente é um dos participantes diretos no desenvolvimento do projeto

2. Os clientes estão entusiasmados com o projeto e o produto?
Sim, eles buscam sempre saber mais informações e ficam no desejo de ver
algo pronto o quanto antes.

3. A equipe de desenvolvimento compreende bem os requisitos?
Sim, uma vez que, todos participaram do processo de elicitação e análise dos
requisitos definidos

4. Os clientes estiveram envolvidos na definição dos requisitos?
Sim, esta etapa foi realizada com todos os membros da equipe de
desenvolvimento, os clientes da Prefeitura e contou com a presença do mediador
Edson.


5. Os requisitos do projeto são estáveis?
Sim, e também são baseados em uma versão anterior do sistema chamado
Sistema de Controle de Serviços – SisCon, haverá apenas a modificação de ambiente,
usabilidade e performance do sistema.

6. A equipe de desenvolvimento tem experiência na tecnologia a implementar?
Os membros já trabalharam juntos em projetos anteriores, mas, com outras
tecnologias.

7. É adequado o número de pessoas da equipa de trabalho?
De acordo com as métricas utilizadas não, pois, precisaríamos de mais um ou
dois membros, mas, a equipe já se conhece e sabe o quê e como pode realizar as
atividades do projeto.

3.2 Tabela de Riscos

Para a elaboração da Tabela de Riscos, durante a reunião de brainstorming,
cada membro do grupo relacionou os possíveis riscos existentes no projeto. Na fase
seguinte atribuímos uma probabilidade de ocorrência e o grau de impacto para cada
risco catalogado.
Feito isto, juntamos as listas e realizamos uma análise circular dos riscos o que
gerou a Tabela 4, abaixo.

Nº Riscos Categoria Prob. Impacto

Razoabilidade do prazo de entrega
1 Negócio 75% Catastrófico
Dúvidas sobre o que a
2 funcionalidade solicitada é capaz de fazer Tecnológico 75% Catastrófico
Ferramentas são integradas com o outro
3 sistema Processo 75% Catastrófico
Tamanho estimado do produto em número
4 de programas Tamanho 50% Critico
Você já trabalhou com o cliente no passado
5 Cliente 90% Marginal
Utilização de novos métodos de
6 engenharia de software Tecnológico 75% Marginal
Quadro de processo comum estabelecido
7 Processo 30% Marginal
Número de mudanças projetadas para as
8 exigências do produto Tamanho 25% Marginal
Tabela 4. Riscos do Projeto


3.3 Estratégias para Gestão de Riscos

Para as estratégias de redução, supervisão e gestão dos riscos (RSGR)
identificados, foram selecionados os principais. São eles:
1. Razoabilidade do prazo de entrega;
2. Dúvidas sobre o que a funcionalidade solicitada é capaz de fazer;
3. Ferramentas são integradas com outros sistemas;
4. Tamanho estimado do produto em número de programas;
5. Você já trabalhou com o cliente no passado;
6. Utilização de novos métodos de engenharia de software.
1. Razoabilidade do prazo de entrega
Risco: 2 Probabilidade: 75% Impacto: Catastrófico
Descrição: Este risco se refere ao prazo estimado que foi calculado, através das
métricas, e o prazo real de entrega do produto para o cliente.
Estratégia de redução: Realizar reuniões semanais com o Professor Edson e
reuniões mensais com o cliente afim de possibilitar a detecção de erros o quanto
antes para a devida correção.
Plano de contingência: Alterar planejamento e negociar novos prazos
Responsável: Tiago Lahan
Status: Em Andamento
Tabela 5. Gestão de Riscos 1

2. Dúvidas sobre o que a funcionalidade solicitada é capaz de fazer
Descrição: Este risco reflete sobre as dúvidas existentes ao longo do
desenvolvimento, tais como funcionalidades do sistema, perfis de usuários e modos
de acesso.
Estratégia de redução: Minimizar ao máximo as incertezas de projeto através de
reuniões de brainstorming e entrevistas com o cliente final e documentar tais
atividades.
Plano de contingência: Realizar novas reuniões só para tirar dúvidas e manter
contato através de email e telefone.
Status: Concluído


3. Ferramentas são integradas com outros sistemas
Descrição: Este risco se refere ao fato do SGS se integrar ao sistema SIE, já
existente, a outras ferramentas e como essa integração será realizada.
Estratégia de redução: Contatar os responsáveis pelo sistema SIE para reuniões
sobre integração para tirar as dúvidas existentes.
Plano de contingência: Pesquisar modos de integração e ferramentas para realizar
estas atividades.
Responsável: Rafael Almeida

4. Tamanho estimado do produto em número de programas
Risco: 4 Probabilidade: 50% Impacto: Crítico
Descrição: Este risco se refere a quantidade de módulos necessários ao
desenvolvimento do sistema.
Estratégia de redução: Determinar o escopo do projeto na fase de Análise e, segui-lo
prontamente ao longo do desenvolvimento
Plano de contingência: Limitar as funcionalidades extras, sem perder o escopo
proposto
Responsável: Tiago Lahan, Rafael Almeida
Status: Concluído

5. Você já trabalhou com o cliente no passado
Risco: 5 Probabilidade: 90% Impacto: Marginal
Descrição: Este risco se refere a falta de conhecimento da equipe de
desenvolvimento com relação ao cliente
Estratégia de redução: Realizar reuniões periódicas para tirar dúvidas e conhecer o
cliente através de técnicas de engenharia de software
Plano de contingência: Manter contato com o cliente através de telefone, email e
reuniões periódicas
Status: Concluído


6. Utilização de novos métodos de engenharia de software
Risco: 5 Probabilidade: 75% Impacto: Marginal
Descrição: Este risco se refere a utilização de novos métodos para o
desenvolvimento do projeto, desde ferramentas case à linguagem de programação
Estratégia de redução: Estudar a linguagem proposta através de cursos, vídeos-aula
e leitura em tutoriais próprios
Plano de contingência: Utilização de plugins que facilitem o desenvolvimento


4. PLANEJAMENTO TEMPORAL

No Planejamento Temporal são definidas as datas de execução das tarefas
assim como, os responsáveis por cada uma delas através do Diagrama de Gantt
elaborado pelo Gerente do Projeto.

4.1 Conjunto de Tarefas do Projeto

Tarefas Porcentagem Dias de trabalho
Planejamento 3% 21
Análise de Requisitos e Modelagem 40 % 280
Codificação 20 % 140
Testes 37 % 259
Tabela 11. Dias por Tarefa

4.2 Diagrama de Gantt

Na Tabela 12, visualizamos o Diagrama de Gantt com as atividades de acordo
com o processo de software. Para este projeto utilizamos metodologia de
desenvolvimento ágil por ter sido desenvolvido no framework Grails.

Figura 11. Diagrama de Gantt


5. ORGANIZAÇÃO DO PESSOAL

Cada membro da equipe possui as suas atribuições e deveres bem definidos,
assim, cada um sabe qual tarefa deve ser realizada e até onde ele pode fazer. As
decisões serão tomadas em conjunto com todos os stakeholders do projeto.

5.1 Estrutura da equipe

• Gerente de Projeto: Sua função é gerenciar o progresso do empreendimento
e através das variáveis (qualidade, custo, prazo e âmbito) verificar seus
desvios. Desta forma, seu objetivo geral é minimizar as falhas inerentes aos
processos.

• Analista de Sistema: estudam os diversos sistemas existentes entre
hardwares (equipamentos), softwares (programas) e o usuário final.

• Projetista de software: mapear as estruturas e funcionalidades identificadas
na análise de requerimentos dentro do contexto e das restrições da arquitetura.
Responsável: Rodrigo Azevedo

• Testador: Faz a investigação do software a fim de fornecer informações sobre
sua qualidade em relação ao contexto em que ele deve operar. Isso inclui o
processo de utilizar o produto para encontrar seus defeitos.
Responsável: Rodrigo Azevedo

5.2 Mecanismos de comunicação

Para um melhor gerenciamento do projeto como um todo, a equipe estabelece
comunicação direta entre seus membros e, cliente. Dessa forma, além do contato
interpessoal ser fortificado a relação existente aumenta a facilidade com que o
problema é entendido.
A monitorização do projeto se dará por reuniões periódicas entre os membros
da equipe e, a cada etapa do processo de desenvolvimento (Planejamento, Análise de


Requisitos, Codificação, Testes) é feita uma avaliação dos resultados obtidos para
possíveis correções e adequação das etapas em cada nível do projeto.

5.3 Uso do Edu-blog como ferramenta de apoio

Achamos o Edu-blog uma excelente ferramenta de apoio à disciplina, pois é
fácil e agradável de utilizar. Permite ao professor disponibilizar todo o material
referente à disciplina e possibilita a comunicação entre o docente e todos os alunos,
sendo muito útil para cada um apresentar as suas dúvidas e sugestões.
A utilização do Edu-blog como ferramenta que auxilie no compartilhamento de
informações é importante, pois cria um canal fixo de comunicação entre todas as
equipes, permitindo um local onde todos possam acessar e pesquisar assuntos que
possam enriquecer o trabalho individual.


Plano de Projeto SGS

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Plano de Projeto SGS

Último

Plano de Projeto SGS