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

Plano de Projeto de Software Página 2

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


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.

Tabela 4. Riscos do Projeto

Nº Riscos Categoria Prob. Impacto

1 Razoabilidade do prazo de entrega

Negócio 75% Catastrófico

2 Dúvidas sobre o que a funcionalidade solicitada é capaz de fazer Tecnológico 75% Catastrófico

3 Ferramentas são integradas com o outro sistema Processo 75% Catastrófico

4 Tamanho estimado do produto em número de programas Tamanho 50% Critico

5 Você já trabalhou com o cliente no passado

Cliente 90% Marginal

6 Utilização de novos métodos de engenharia de software Tecnológico 75% Marginal

7 Quadro de processo comum estabelecido

Processo 30% Marginal

8 Número de mudanças projetadas para as exigências do produto Tamanho 25% Marginal


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

Education