1

SUMÁRIO

1.0 3
INTRODUÇÃO..............................................................................................................

1.1 DESCRIÇÃO DO 3
PROJETO....................................................................................
1.2 PRINCIPAIS FUNÇÕES DO 3
SISTEMA.....................................................................
1.3 RESTRIÇÕES....................................................................................................... 3

2.0 ESTIMATIVA DO PROJETO........................................................................................... 4

2.1 DADOS HISTÓRICOS........................................................................................... 4

2.2 DADOS DE ESTIMATIVAS E RESULTADOS............................................................ 4

2.2.1 TECNICAS DE 4
ESTIMATIVA........................................................................

2.3 RESULTADOS..................................................................................................... 5
2.4 RECURSOS DO PROJETO..................................................................................... 5
2.5 DIAGRAMA DE GANTT....................................................................................... 7

3.0 ANALISE E GESTÃO DE RISCOS..................................................................................... 8

3.1 RISCOS DO PROJETO.......................................................................................... 8

3.2 TABELA DE RISCOS............................................................................................. 9
3.3 REDUÇÃO E GESTÃO DE RISCOS.................................................................... 10

4.0 ORGANIZAÇÃO DO PESSOAL....................................................................................... 11

4.1 ESTRUTURA DA EQUIPE..................................................................................... 11

4.2 MECANISMOS DE COMUNICAÇÃO..................................................................... 12
4.3 USO DO EDU-BLOG COMO FERRAMENTA DE APOIO.......................................... 12

2
1.0 INTRODUÇÃO

Esta seção descreve uma visão geral sobre o projeto de software, mostrando suas principais
funcionalidades e algumas restrições na implantação na UFS.

1.1 DESCRIÇÃO DO PROJETO

Este Módulo de extensão é parte de um sistema maior de Administração acadêmica, pois na

UFS administração acadêmica abrange Ensino, Pesquisa e Extensão, ficando esse último com
parte social da atividade fim da UFS.

A atividade de extensão na UFS passa por uma aprovação de resolução pelo conselho de
ensino e pesquisa (CONEP). Sendo assim, uma atividade de extensão segundo a resolução da
UFS pode ser: projetos, cursos, eventos, produtos e prestação de serviços. Com isso um
professor ou um técnico administrativo de nível superior poderá solicitar aprovação de
qualquer uma dessas atividades ao setor gestor (PROEX) dessa modalidade.

O gestor entra com os editais e os calendários de execução dos projetos, isso deve ser definido
nos perfis de cada usuário que faz login no sistema. Os professores e técnicos entram com as
solicitações de suas atividades de extensão e os estudantes fazem os relatórios das atividades
propostas a eles junto com os técnicos administrativos e professores.

As atividades podem ser financiadas ou não por órgãos conveniados com a UFS.

Os professores ou técnicos podem solicitar mais de uma atividade de extensão, sendo que o
conjunto dessas atividades em numero de 5 torna-se um programa de atividades.

1.2 PRINCIPAIS FUNÇÕES DO SISTEMA

As principais funções são:

O sistema deve ser capaz de prover papeis de usuários para quando os mesmos fizerem o
login, apenas os módulos autorizados possam ser acessados por eles;

Deve prover relatórios mensais, semestrais e anuais para os gestores das atividades;

Deve ser capaz de inabilitar um professor ou técnico em uma próxima temporada de

solicitação de atividades caso estes não tenham cumprido as metas das atividades solicitadas
anteriormente.

1.3 RESTRIÇÕES

A principal restrição encontrada até o momento está na configuração de mudanças, pois

muitas funcionalidades estão sendo mudadas tanto na UFS quanto na UFRN e os merges estão
sendo difíceis de administrar.

Merge refere-se a integração dos sistemas tanto na UFS quanto na UFRN.

3
2.0 ESTIMATIVAS DO PROJETO

Esta seção mostrará as estimativas de custo, esforços e tempo. Sabendo o prazo para cumprir
o projeto, o gestor poderá planejar melhor as questões de recursos que abrange pessoas e
custos.

2.1 DADOS HISTÓRICOS

Como se trata da primeira vez que faço esse tipo de calculo para gerência de projeto de
software, não tenho dados históricos para apresentar.

2.2 TECNICAS DE ESTIMATIVAS E RESULTADOS

É demonstrado aqui como efetuar o cálculo para encontrar o prazo total de duração do
projeto (em dias). Foi utilizada a métrica de Lorenz & Kidd, aconselhada pela Lacertae Software
para estimar o prazo total deste projeto.

2.2.1 TECNICAS DE ESTIMATIVA

Foi utilizada a técnica de estimativa do CPD UFS Produção de Software Ltda que é uma métrica
orientada a classes onde se destaca por ser simples e fácil de utilizar e segue as regras da
métrica de Lorenz & Kidd.

Para usar esta métrica devemos seguir alguns 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
estimativa do número de classes de suporte;
4. Logo após, 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. Calculo do tempo previsto para a elaboração do projeto.

A tabela abaixo mostra os fatores de multiplicação para encontrar a quantidade de classes de

suporte:
Interface Multiplicador
Não gráfica 2
Baseada em texto 2,25
GUI 2,5
GUI complexa 3
Tabela de fator de multiplicação

4
2.3 RESULTADOS

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

1. Quantidade de classes chaves = 10;
2. Este sistema rodará na WEB então utilizarei a interface gráfica GUI = 2,5;
3. Classes chaves x multiplicador (10 x 2,5) = 25 classes de suporte;
4. Classes chaves + classes de suporte (10 + 25) = 35 classes projetada para o sistema;
5. Como na empresa não tenho experiência para saber exatamente a quantidade de dias-
pessoa, escolherei o valor mínimo sugerido por Lorenz & Kidd. Neste caso 15 dias-
pessoa;
6. Posso agora calcular a quantidade de esforço estimada: (35 x 15) = 525 dias de
trabalho;
7. Agora vou calcular os dias corridos para construir o sistema, incluindo os fins de
semana, fazendo a multiplicação dos dias de trabalho com os 30 dias do mês e dividirei
por 22 dias uteis: (525 x 30) = 15.750 ÷ 22 = 715,90 ≈ 716 dias corridos. Para saber os
meses corridos basta dividir o resultado por 30. (716 ÷ 30) = 23,86 ≈ 24 meses
corridos.

A equipe para desenvolvimento deste projeto contem 4 membros, posso então calcular a
distribuição dos dias de trabalho por pessoa. Com isso tenho 525 ÷ 4 = 131,25 ≈ 131 dias por
pessoa.

Aplicando a distribuição dos dias de trabalho aos percentuais de cada fase tenho a seguinte
situação:

Modelo % modelo % projeto Cálculo Dias trabalho

Planejamento 2 – 3% 3% 525 x 3% ≈ 16
Requisito-Analise-Desenho 40% 40% 525 x 40% 210
Geração de código 20% 20% 525 x 20% 105
Testes 37-38% 37% 525 x 37% ≈194
Resultado 525
Tabela dos dias para termino do projeto

2.4 RECURSOS DO PROJETO

Os recursos usados para elaboração deste projeto serão: humanos, de software, hardware e
bibliográficos.

Em relação aos recursos humanos, como esse sistema na UFS trata-se muito mais de gerencia
de configuração e mudanças, a fase que trata do planejamento: modelagem do negócio,
requisitos, analise e design, implementação, teste e implantação que é a principal fase de
construção do sistema, está a cargo dos profissionais da instituição UFRN, então esta
instituição será colocada como um dos profissionais responsáveis pelo sistema e aparecerá no
diagrama de Gantt.

5
Recursos humanos:
A equipe de desenvolvimento do projeto é formada por quatro membros, são eles:

UFRN
· Gestor de Projeto
· Analista de sistemas
Sigelman Araujo
· Gestor de Projeto
· Analista de sistemas
Diego Cortes
· Analista de Sistemas
· Programador de Software
· Engenheiro de Software
Vinicius
· Programador de Software
Carla Cássia
· Testadora de Software

Recursos de Software:
Para o desenvolvimento deste projeto foram utilizadas as seguintes ferramentas de software:

· Eclipse, software que dá apoio ao desenvolvimento em Linguagem de programação JAVA.

· Java, linguagem de programação orientada a objetos, para a construção e manutenção dos
softwares com recursos para WEB.
· Postgres, sistema de gerência de banco de dados relacional muito usado em empresas e por
grandes sistema corporativos.
· Pgadmin, software para facilitar os acessos ao banco de dados para uma melhor
administração visual do mesmo.
· MsProject, utilizado para facilitar a administração do projeto.
· Microsoft word, para fazer documentações simples.
· Internet Explorer, browser de Internet.
· Mozila Firefox, browser de Internet.
. Linux Ubuntu ou Debian, sistemas operacionais.
. Windows 7, sistema operacional.
. Hibernate, Software utilizado para fazer relação objeto-relacional.
. Struts, software utilizado para relacionar regras de negócio.

Recursos Hardware:
Os hardwares utilizados para elaboração do projeto são:
· Computadores Pessoais PC da HP
· Impressora para testes de impressão

Recursos Bibliográficos:
O recurso bibliográfico utilizado foi o que segue:
PRESSMAN, Roger S. Engenharia de Software, 6ª edição, São Paulo, McGraw-Hill, 2006

6
2.5 DIAGRAMA DE GANTT

O diagrama de Gantt é ilustrado a seguir, trata-se de um gráfico que mostra todas as tarefas
planejadas com suas datas de inicio e fim e os recursos utilizados.

Imagem do diagrama de Gantt parte 1

Imagem do diagrama de Gantt parte 2

7
3.0 ANÁLISE E GESTÃO DE RISCOS
A análise de riscos é importante para um projeto, pois assim o gestor pode se prevenir para
saber administrá-los.

3.1 RISCOS DO PROJETO

Existe um subconjunto de riscos que estão presentes em qualquer projeto de software, riscos
gerais, que são indicados na tabela seguinte:

Risco Projeto Técnic Negócio Comum Especial

o
Equipamento não disponivel X
Requisitos incompletos X X
Uso de metodologias especiais X X
Problemas na busca da X X
confiabilidade requerida
Retenção de pessoas chave X X
Sub-estimativa do esforço X X
Tabela de subconjunto de riscos

Avaliação global dos riscos:

1. O Gestor de Software dá suporte ao projecto?

Sim, os gestores do software tanto na UFRN quanto na UFS, principalmente o
primeiro, que tem uma gestão de solicitações e demandas, para dar total suporte ao
projeto como um todo.

2. Os Clientes estão entusiasmados com o projecto e o produto?

Sim, os clientes ao fazerem treinamentos nas versões colocadas para este fim, ficaram
entusiasmados com a possibilidade de implantação do sistema no ambito da UFS.

3. Os Engenheiros de Software compreenderam bem os requisitos?

De acordo com as resoluções da UFRN, os requisitos foram bem compreendidos,
faltando apenas analisar se haverá alguma mudança em relação as resoluções da UFS,
porém as mudanças serão minimas, pois se tratam de dois orgão afins.

4. Os Clientes estiveram envolvidos na definição dos requisitos?

Não posso afirmar em relação a UFRN, porém em relação a UFS, os clientes estão bem
envolvidos, participando de todos os treinamentos e discutindo as possibilidades de
mudanças e querendo saber o que tem e o que não tem implantado no sistema para
satisfazer suas necessidades.

5. O âmbito do projeto é estável?

Por enquanto o projeto ainda não está estável na UFS, pois as configurações e
mudanças, principalmente nas tabelas de banco de dados de dominio, ainda estamos
trabalhando muito com elas.

6. Os engenheiros de Software têm as competências requeridas?

Sim, os engenheiros são bem capacitados para gerir as configurações e mudanças no
sistema.

8
 7. Os requisitos do projeto são estáveis?
Sim, de acordo com os treinamentos, os requisitos implantados, parece não precisar
de mudanças, se alguma mudança for feita, será mais para acrescentar do que para
tirar ou alterar.

8. A Equipe de Desenvolvimento tem experiência na tecnologia a

implementar?
Todos na UFS foram capacitados com cursos nas tecnologias, principalmente de
software, para a implantação do sistema.

9. É adequado o número de pessoas da equipa de trabalho?

Não. Mas como as dificuldades de contratação de pessoal é grande, exigirá muito
esforço por parte da equipe.

3.2 TABELA DE RISCOS

Segue abaixo a lista dos riscos identificados no projeto:

Risco Categoria Probabilidade Impacto

Insuficiência de Pessoal 80% Crítico
pessoas na equipe
Prazo para entrega Tecnico 80% Crítico
curto
Treinamento Características do 30% Marginal
Usuários Docente e Cliente
Discentes
Mudanças nos Projeto 10% Crítico
requisitos
Falta de Motivação Pessoal 70% Marginal
Rotatividade de Pessoal 20% Catastrófico
pessoal
Conflitos Pessoal 20% Marginal
Tecnologia e Tecnico 10% Catastrófico
infraestrutura
(danos)
Capacidade da Pessoal 10% Crítico
equipe
Perda de dados na Técnico 80% Catastrófico
Integração dos
sistemas
Tabela dos riscos encontrados no projeto

9
3.3 REDUÇÃO E GESTÃO DE RISCOS
Dos itens elencados foram escolhidos dois com impacto critico e um com impacto
catastrófico para descrevermos as suas atividades de redução, supervisão e
gestão do risco.

Na instituição existe um numero pequeno de profissionais de TI, até mesmo pela

dificuldade na contratação dos mesmos, pois para isso deve-se abrir concurso
publico ou licitação para contratação de terceirizados e deve existir verba para
aprovação.

Insuficiência de pessoas na equipe

Risco:001 Probabilidade: 80% Impacto: Crítico
Descrição: O numero de profissionais efetivos no CPD da UFS é reduzido.

Estratégia de redução: Como o CPD da UFS não tem autonomia para

contratação de pessoal, deve-se buscar com setores superiores formas de
contratação de pessoal.
Plano de contingência: havendo dificuldades de abertura de concursos públicos,
abrir processo de licitação para contratação de terceirizados.
Pessoa responsável: Sigelman Araujo
Status: Simulação completada

Muitas perdas de dados nos códigos ocorrem quando se faz a integração dos
dados entre a UFRN e a UFS.

Perda de dados na integração dos sistemas

Risco:002 Probabilidade: 80% Impacto: Catastrófico
Descrição: Ao efetuar a integração dos repositórios UFS e UFRN, perdas de
dados existem.

Estratégia de redução: Quando desenvolvemos em paralelo com o pessoal da

UFRN, ainda está prevalecendo o repositório deles, sobrepondo as nossas
mudanças no momento da integração, então devemos trabalhar para o mais
rápido possível para ficarmos independente do desenvolvimento da UFRN e
trabalharmos as nossas demandas locais sem precisar fazer a integração com
eles.
Plano de contingência: Fazer todo estudo necessário com a UFRN para que a
parte essencial dos requisitos do sistema esteja de acordo com as necessidades
da UFS e assim eles liberarem o módulo, deixando os profissionais deles livres
para outras tarefas e nós de cá a vontade com as nossas demandas locais.
Pessoa responsável: Diego Cortes
Status: Simulação Incompleta

10
Algumas mudanças de requisitos podem ocorrer, pois apesar de as instituições
parecerem devido as suas atividades fins, algumas mudanças locais podem
acontecer.

Mudanças nos requisitos

Risco:003 Probabilidade: 10% Impacto: Crítico
Descrição: Os requisitos da UFRN forem diferentes dos da UFS.
Estratégia de redução: sabendo que a fase de construção do software cabe a
UFRN, devemos alertá-los o mais rápido possível para que haja um novo
versionamento do sistema para a UFS.
Plano de contingência: o Gestor deve trabalhar com a equipe da UFRN
mostrando para eles como devem ser o comportamento dos nossos requisitos.
Pessoa responsável: UFRN e Sigelman Araujo
Status: Simulação Incompleta

4.0 ORGANIZAÇÃO DO PESSOAL

A nossa equipe segue uma estrutura descentralizada democrática, pois, apesar de termos um
gestor competente responsável pela organização dos trabalhos, as decisões são tomadas em
conjunto e com o consenso de todos e a comunicação é horizontal. Além disso, esta é a melhor
estrutura para problemas complexos e que requerem muita comunicação, além de ser a que
produz melhores ambientes e satisfação no trabalho.

4.1 ESTRUTURA DA EQUIPE

A equipe é formada por cinco elementos e logo no inicio dos trabalhos definimos claramente
as funções de cada um, sendo:

UFRN - Gestor de Projeto e Analista de sistemas;

Sigelman Araujo - Gestor de Projeto e Analista de sistemas;
Diego Cortes - Analista de Sistemas, Programador de Software e Engenheiro de Software;
Vinicius - Programador de Software e
Carla Cássia - Testadora de Software.

O gestor tem a responsabilidade de coordenar todo o desenvolvimento do projeto,

combinando reuniões, distribuindo tarefas, resolver conflitos e manter a motivação e bom
ambiente no seio do grupo, alem de ser responsável pelo planejamento temporal do projeto
compondo o diagrama de Gantt.

O analista de sistema tem a função de analisar o software e desenhar os vários diagramas do

sistema e criar as classes e interfaces a implementar.

O engenheiro de software estuda e seleciona tanto as ferramentas utilizadas como o hardware

e plataformas onde o software será utilizado.

Os programadores recebem o trabalho do analista e programam o código do novo sistema.

O testador no fim testa exaustivamente todo o sistema de forma a detectar erros na

implementação.

11
4.2 MECANISMOS DE COMUNICAÇÃO

A comunicação entre todos os elementos da equipe é feita principalmente através de reuniões

periódicas, resolvem-se problemas em conjunto e distribuem-se tarefas. Além disso, são
também utilizados os meios de comunicação eletrônica, através de correio eletrônico e MSN
Messenger, e meios de comunicação telefônica.

4.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.

Em relação aos blogs de cada equipe, achamos que é também interessante na medida em que
permite a cada grupo partilhar com a comunidade o desenvolvimento do seu trabalho,
disponibilizando arquivos, bem como receber sugestões e criticas de qualquer pessoa. No
entanto para comunicação entre os membros da equipe, utilizamos o MSN Messenger.

12