Este documento apresenta o plano de projeto para o desenvolvimento de um sistema chamado e-Litter, que irá auxiliar na manutenção de dados de coletas de materiais orgânicos realizadas em pesquisas de biologia. O documento descreve o escopo do projeto, suas principais funções, requisitos, estimativas de tempo e custo utilizando a técnica de Lorenz & Kidd, recursos envolvidos e uma análise de riscos.

1. Universidade Federal de Sergipe
Departamento de Computação
Bacharelado em Ciência da Computação
Disciplina: Tópicos Esp. em Engenharia de Software
Plano do Projeto
e-Litter
Equipe: Rafael Mendonça França
Rubens de Souza Matos Júnior
Docente: Rogério P. C. Nascimento
Março de 2008

2. 1 INTRODUÇÃO
Esta seção descreve uma visão geral sobre o projeto de software, iniciando com uma
descrição do seu âmbito, em seguida enumera as principais funções que o sistema deve
assegurar. Descreve-se também quais são os requisitos de comportamento e temporais
da aplicação e logo após fala-se das restrições técnicas e temporais existentes no
projeto.
1.1 Âmbito do Projeto
Este documento tem como objetivo apresentar o projeto de desenvolvimento da
aplicação e-Litter, que permitirá a manutenção informatizada dos dados das coletas de
materiais orgânicos realizadas em pesquisas do Departamento de Biologia da UFS e a
geração de relatórios e gráficos descritivos do ambiente estudado.
A principal cliente será a profª Myrna Landim, do Departamento de Biologia da
Universidade Federal de Sergipe, que realiza pesquisas referentes ao material orgânico
produzido pela vegetação de mangue. Além do projeto relacionado a mangues, existem
outros, realizados em tipos de ambientes diferentes, como a mata atlântica.
Os dados das coletas realizadas são organizados e totalizados para que possam ser
feitas análises estatísticas do depósito de serapilheira (material orgânico) ao decorrer de
um período, que geralmente é de um ano. Essa análise é feita através de tabelas com a
totalização dos dados, e de gráficos comparativos.
O sistema terá ainda um administrador responsável por cado projeto do sistema,
podendo somente ele cadastrar outros participantes do projeto e alteração de alguns
dados (tipos de materiais alvo do projeto) na base de dados.
1.2 Funções principais do produto de software
As seguintes funcionalidades serão disponibilizadas pela aplicação:
• Deve ser um sistema seguro – Somente os responsáveis e os outros
participantes definidos por eles deverão ter acesso aos dados, assim como poder
modificá-los.
• Cadastrar e manter dados de coletas.
• Manter lista de áreas de coleta.
• Manter lista de locais de coleta.
• Manter lista de pontos de coleta.
• Manter lista de tipos de ambiente.
• Manter lista de espécies.
• Manter lista de tipo de material.
• Definir equivalências entre tipos de materiais.
• Manter dados climáticos das regiões onde são realizadas as pesquisas.
• Gerar gráficos da produção de serapilheira em relação a um determinado período
de tempo.
• Gerar relatórios da produção de serapilheira em relação a um determinado
período de tempo.
1.3 Requisitos comportamentais ou de performance
O sistema deve ser confiável, ou seja, não deve ser encerado abruptamente Também
deve ser mantida a consistência entre os dados cadastrados e aqueles apresentados ao
usuário.
O sistema também deve ser de fácil manutenção e evolução do conjunto de
funcionalidades. Tem que ter uma interface rica e de fácil aprendizagem e utilização.
1.4 Gestão e Restrições Técnicas
1

3. O sistema deverá ser desenvolvido utilizando apenas ferramentas em plataformas
gratuitas. O projeto só poderá contar com 2 desenvolvedores, que cumprirão também
todos os outros papéis.
O planejamento correto é essencial para o sucesso do desenvolvimento do projeto,
para isso, é necessário um conhecimento razoavelmente coerente sobre o desempenho
dos participantes no projeto, a duração das tarefas, as fases e os requisitos que temos
de definir e outros tópicos essenciais. Alguns desses requisitos exigem um cálculo
intuitivo da sua duração, porém pode ser que nem sempre esta estimativa esteja
correta, tornando-se por isso uma restrição em termos temporais.
2 ESTIMATIVAS DO PROJETO
As estimativas do projeto são importantes no sentido em que o gestor terá uma maior
percepção da longevidade que o projeto terá, ou seja o tempo total do projeto. Por sua
vez também pode efetuar os cálculos necessários para determinar o tempo de cada fase
do projeto, fase de planeamento, requisitos-análise-desenho, implementação e testes.
2.1 Dados históricos utilizados para as estimativas
No momento não possuímos quaisquer dados históricos visto que nenhum elemento
da equipe contém experiência na realização de projetos de software, exceto por
experiências acadêmicas.
2.2 Técnicas de estimação e resultados
Nesta seção é demonstrado como efetuar todo o cálculo para encontrar o tempo total
de duração do projeto (em dias). E para encontrar esse tempo é necessário aplicar uma
técnica de estimação, que neste caso utilizaremos a métrica de Lorenz & Kidd,
aconselhada pela Lacertae Software.
2.2.1 Técnica de estimação
A técnica de Lorenz & Kidd é uma métrica orientada a classes onde se destaca por ser
simples e fácil de utilizar. Podemos então mencionar a definição de métrica para que não
restem duvidas do que é uma métrica: “Medida quantitativa do grau de posse de um
atributo dado por parte de um sistema, componente ou processo”.
Para usar a métrica de Lorenz & Kidd temos que:
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
Interface Multiplicador
não gráfica 2
baseada em texto 2,25
GUI 2,5
GUI complexa 3
Tabela 1 - Relação entre tipo de interface e índice de
multiplicação
3. Multiplicar a quantidade de classes-chave pelo Multiplicador para obter uma
estimativa do número de classes de suporte
2

4. 4. Em seguida, calcula-se a quantidade total de Classes, somando o nº de Classes-Chave
com o nº de Classes de Suporte.
5. Multiplicar a quantidade total de Classes (classes-chave + classes de suporte) pelo
“número médio de unidades de trabalho (dias-pessoa) por classe”. Lorenz & Kidd sugere
entre 15 e 20 dias-pessoa por classe. Escolher um número entre 15-20 dias-pessoa e
justificar a escolha.
6. Determinar a quantidade de esforço estimada.
7. Calculo do tempo previsto para a elaboração do projeto
2.3 Resultados
Com base na métrica de Lorenz & Kidd descrita acima, obtivemos os resultados
seguintes:
1. Nº classes chave = 19
2. Escolhemos a interface com base na aplicação gráfica que irá ter o produto final.
Multiplicador da GUI = 3
3. 19 X 3 = 57
Logo teremos 57 Classes de Suporte.
4. O número total de classes é igual a:
Nº Classes Chave + Nº Classes de Suporte = 19 + 57 = 76
5. Em seguida, escolhe-se o número médio de unidades de trabalho (dias-pessoa) por
classe onde a métrica Lorenz & Kidd sugere entre 15 e 20 dias-pessoa por classe. Em
conjunto optamos por escolher 16 dias-pessoa devido ao fato de estarmos familiarizados
com as nossas ferramentas de trabalho, como por exemplo o “Eclipse”, o “PostgreSQL”,
quot;Microsoft Project 2003quot;, quot;StarUMLquot; e a linguagem quot;Javaquot;, em relação a deixar as coisas
para fazer para última hora até que não é o nosso lema de trabalho, mas às vezes, como
existem outros trabalhos paralelamente, nem sempre é possível fazer tudo como
pretendíamos.
6. Sendo assim o cálculo da quantidade do esforço estimada é:
76 X 16 = 1216 dias-pessoa de trabalho
Poderemos calcular agora os dias de trabalho por pessoa, e como temos 2 elementos na
equipe, para dividir os 1216 dias de trabalho, ficaremos com aproximadamente 608 dias
de trabalho para cada elemento de equipe.
7. Agora se pretendemos ter os dias e meses corridos (incluindo os fins de semana),
temos que multiplicar os dias de trabalho com os 30 dias corridos e em seguida dividir
pelos os 22 dias úteis.
608 X 30 = 18240 / 22 = 829,09 ~ 829 dias corridos
829 / 30 = 27,63 ~ 27 Meses corridos
Sabendo-se os dias de trabalho totais (608 dias), estes dias são agora distribuídos de
acordo com as seguintes percentagens de distribuição dos componentes essenciais num
projeto:
1) Planejamento: 2-3%
2) Requisitos – Análise – Desenho: 40%
3) Geração de Código: 20%
4) Testes: 37-38%
3

5. Os valores calculados são:
1) Planejamento: 608 * 3% = 18 dias de trabalho
2) Requisitos – Análise – Desenho: 608 * 40% = 243 dias de trabalho
3) Geração de código: 608 * 20% = 122 dias de trabalho
4) Testes: 608 * 37% = 225 dias de trabalho
Total: 608 dias de trabalho
2.4 Recursos do projeto
Iremos enumerar a seguir todos os recursos usados para elaboração desde projeto, os
recursos podem ser: humanos, de software, hardware e bibliográficos.
Recursos humanos:
A equipe de desenvolvimento do projeto é formada por dois elementos, sendo eles:
Rafael Mendonça França - 03110260
• Gestor do Projeto
• Programador de Software
Rubens Matos - 04111044
• Analista de Sistemas
• Testador de Software
Recursos de Software:
Para o desenvolvimento de todo o nosso projeto foram utilizadas as seguintes
ferramentas de software:
• Eclipse 3.3 da empresa Eclipse para a criação da aplicação de software.
• Google Docs, processamento de texto web para a criação dos vários
documentos a disponibilizar ao diretor e aos clientes.
• dotProject, utilizado para fazer o planejamento de todas as tarefas do projeto.
• PostgreSQL , sistema gerenciador de banco de dados livre muito usado em
empresas e por grandes sistema corporativos.
• Mozilla Firefox, browser de Internet.
Recursos Hardware:
Em relação aos recursos de hardware utilizados para elaboração do projeto são
basicamente os computadores pessoais dos elementos da equipe.
• Computadores Desktops dos membros da Equipe.
Recursos Bibliográficos:
Estes são os recursos mais importantes na ausência de conhecimento sobre algum
tema ou área específica, assim sendo foram utilizamos para ganhar os tais
conhecimentos que nos faltavam para conseguirmos elaborar este projeto.
• Nascimento, Rogério – Engenharia de Software, http://w3.ualg.pt/
~rnascimento/
3 ANÁLISE E GESTÃO DE RISCOS
Um risco é um problema potencial e todos os projetos estão sujeitos a determinados
riscos que não podem ser ignorados, antes pelo contrário, devem
ser alvos de uma exaustiva análise e há que saber geri-los de forma a tentar evitá-los ou
minimizá-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:
4

6. Risco Projecto Técnico Negócio Comum Especial
Equipamento não disponível X
Requisitos incompletos X X
Uso de metodologias especiais X X
Problemas na busca da confiabilidade X X
requerida
Retenção de pessoas chave X X
Sub-estimativa do esforço X X
Tabela 2 - Tabela que indica os riscos gerais do projeto.
Avaliação Global do Risco:
1. O Gestor de Software dá suporte ao projeto?
Sim. O gestor de Software é participante ativo de todo o projeto.
2. Os Clientes estão entusiasmados com o projeto e o produto?
Sim. O cliente está satisfeito com todos os resultados apresentados.
3. Os Engenheiros de Software compreenderam bem os requisitos?
Sim. Os Engenheiros de Software está ciente de todos os requisitos do produto.
4. Os Clientes estiveram envolvidos na definição dos requisitos?
Sim. Os Clientes participam de todas as definições dos requisitos.
5. O âmbito do projeto é estável?
Não. O âmbito do projeto já foi modificado várias vezes em busca de uma melhor
viabilidade do produto
6. Os engenheiros de Software têm as competências requeridas?
Apesar da pouco experiência, os Engenheiros de Software têm ótimas capacidades e a
competência necessária para a elaboração do projeto.
7. Os requisitos do projeto são estáveis?
Não. Os requisitos tem sofrido modificações afim de melhorar a qualidade do produto.
8. A Equipa de Desenvolvimento tem experiência na tecnologia a implementar?
Sim. A equipe tem experiência com os elementos utilizados no projeto.
9. É adequado o número de pessoas da equipe de trabalho?
Não. O trabalho é extenso para um reduzido número de pessoas o que leverá um esforço
complementar para cada um.
3.2 Tabela de riscos
Na tabela 3 encontram-se descritos todos os riscos identificados no projeto. Os riscos
estão enumerados da seguinte forma, na primeira coluna encontra-se a descrição do
5

7. risco, na segunda coluna a categoria do risco, na terceira a probabilidade de o risco
acontecer e na quarta o tamanho de impacto que o risco pode causar no projeto.
N° Risco Categoria Probabilidade Impacto
01 Data de entrega muito justa Negócio 80% Crítico
02 Âmbito instável Tamanho 40% Crítico
03 Objetivos mal compreendidos Negócio 20% Crítico
04 Indefinição de papeis e responsabilidades Pessoal 35% Marginal
05 Mudança nos requisitos Negócio 25% Crítico
06 Ferramentas inadequadas/inexistentes Negócio 20% Crítico
07 Falta de formação nas ferramentas Pessoal 20% Crítico
08 Insuficiente número de pessoas na equipe Pessoal 80% Crítico
09 Extravio do trabalho efetuado Pessoal 10% Catastrófico
10 Sub-estimativa do tempo/esforço Tamanho 60% Crítico
11 Falta de motivação Pessoal 40% Crítico
12 Conflitos entre os participantes Pessoal 10% Catastrófico
13 Retenção de pessoas-chave Pessoal 15% Catastrófico
Tabela 3 - Tabela de Riscos
3.3 Redução e Gestão de Risco
Apresentaremos aqui estratégias de gestão e redução para três dos riscos
relacionados anteriormente: Âmbito instável, Falta de formação nas ferramentas e
Extravio de trabalho efetuado.
Falta de formação nas ferramentas
Risco:07 Probabilidade: 20% Impacto: Crítico
Descrição: A equipe não possui a formação necessária nas ferramentas a serem
utilizadas
Estratégia de redução: Reservar tempo para treinamento da equipe
Plano de contingência: Troca de ferramentas, contratação de pessoal especializado
Pessoa responsável: Rafael Mendonça
Status: Controlado
Âmbito instável
Risco:02 Probabilidade: 40% Impacto: Crítico
Descrição: Conjunto de funcionalidades do software pode sofrer alterações com
freqüência.
Estratégia de redução: Fixar com o cliente uma prazo para adição de novas
funcionalidades.
6

8. Plano de contingência: Negociar com o cliente aumentos de prazo e retorno financeiro.
Pessoa responsável: Rubens de Souza
Status: Controlado
Extravio de trabalho efetuado
Risco:09 Probabilidade: 10% Impacto: Catastrófico
Descrição: Perda total ou parcial de códigos-fonte ou documentação do projeto
Estratégia de redução: Efetuar backups periódicos, com controle de versão.
Plano de contingência: Recuperar as cópias de backup mais atualizadas.
Pessoa responsável: Rafael Mendonça
Status: Simulação efetuada
4 PLANEJAMENTO TEMPORAL
No planeamento temporal define-se as datas de execução das tarefas e os
responsáveis pelas tarefas, este processo designa-se Diagrama de Gantt, cuja
responsabilidade pertence ao Gerente do projeto.
4.1 Conjunto de Tarefas do Projeto
O modelo de processo de desenvolvimento foi o modelo Clássico, ou em cascata,
tendo todas as funcionalidades implementadas, para só então apresentar o produto ao
cliente e obter o feedback necessário para as melhorias e correções. Este modelo foi o
que mostrou-se mais adequado às circunstâncias, devido a este projeto ser uma
continuação de um anterior, no qual a maioria das funcionalidades já haviam sido
implementadas, parcial ou completamente.
Após ter sido feita a Estimação do Projeto, a divisão do plano de tarefas pela
percentagem de tempo foi efetuada da seguinte forma:
Tarefas Porcentagem Dias de atividade
Planejamento 3% 18
Requisitos - Análise – Desenho 40% 243
Geração de código 20% 122
Testes 37% 225
5 ORGANIZAÇÃO DO PESSOAL
Devido ao fato da equipe possuir apenas 2 integrantes, ficou estabelecida uma divisão
de funções não restritiva. Isto significa que apesar de haver responsabilidades
específicas para cada um, as atividades são desenvolvidas de forma colaborativa, a fim
de agilizar ao máximo o trabalho.
7

9. 5.1 Estrutura da equipe
Os 2 integrantes da equipe são:
Rafael de Mendonça França - Gerente de Projeto e Programador de Software
Rubens Matos - Analista de Sistema e Testador de Software
O Gerente de Projeto tem a responsabilidade de coordenar todo o desenvolvimento
do projeto, combinando reuniões, distribuindo tarefas. Ele é responsável pelo
planejamento temporal do projeto, elaborando o diagrama de Gantt e algumas outras
possíveis formas de delineamento das ações a serem executadas.
O Analista de Sistema deve fazer o levantamento de requisitos e a análise do
software, assim como elaborar diagramas do sistema e estabelecer quais classes e
interfaces devem ser implementadas.
O Programador recebe o trabalho do analista e implementa o código do sistema.
O Testador verifica exaustivamente se o sistema funciona da maneira esperada e
planejada, de forma a detectar erros na implementação.
5.2 Mecanismos de comunicação
A comunicação entre os membros da equipe é realizada durante as aulas da
disciplina, de maneira presencial, e também em outros horários disponíveis para os
membros, através de correio eletrônico, softwares de mensagens instantâneas, como
MSN Messenger e GTalk, e anotações no Google Docs, onde os documentos são
elaborados colaborativamente. As formas de comunicação eletrônica foram de
fundamental importância, devido a incompatibilidades de horários dos integrantes da
equipe e a dificuldade em cumprir todas as atividades dentro do tempo das aulas
práticas.
5.3 Uso do Edu-blog como ferramenta de apoio
O Edu-blog mostrou-se uma ferramenta de fácil utilização e eficiente no propósito de
disponibilizar os documentos produzidos durante o projeto. Devido a exisitirem somente
2 membros na equipe, decidiu-se utilizar o edu-blog de um deles, Rubens de Souza,
para centralizar a documentação. Isto foi feito para evitar possíveis problemas de
diferenças entre versões, caso fossem usados os blogs dos dois integrantes. A utilização
de outras ferramentas de comunicação também foi um motivo para que não criássemos
um blog exclusivo para a equipe.
6 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO
PRODUTO DE SW
Para assegurar e controlar a qualidade do produto de Software, é necessário ter
diversos cuidados, segue-se assim uma descrição de todas as medidas tomadas para
assegurar a qualidade dos produtos de software desenvolvidos pela equipe:
• Acompanhamento e Controle do Projeto de SW – Acompanhamento contínuo do
trabalho desenvolvido por parte de todos os participantes no projeto.
• Produção de Documentação – Elaboração de documentos em relação ao plano do
projeto e às especificações do produto.
• Gestão de Reutilização – Preocupação por parte do programador de implementar
código reutilizável, assim como do analista de elaborar classes que facilitem
essa tarefa.
8

10. • Análise de Riscos – Identificação de todos os riscos inerentes ao projeto e
elaborar os planos de redução e de contingência.
• Testes – Execução exaustiva de teste do sistema com o objetivo de identificar
possíveis erros antes que estes se transformem em defeitos.
9