Universidade Federal de SergipeDepartamento de Computação

Bacharelado em Ciência da ComputaçãoDisciplina: Tópicos Esp. em Engenharia de Software

Plano do Projetoe-Litter

Equipe: Rafael Mendonça FrançaRubens de Souza Matos Júnior

Docente: Rogério P. C. Nascimento

Março de 2008

1 INTRODUÇÃO

Esta seção descreve uma visão geral sobre o projeto de software, iniciando com umadescrição do seu âmbito, em seguida enumera as principais funções que o sistema deveassegurar. Descreve-se também quais são os requisitos de comportamento e temporaisda aplicação e logo após fala-se das restrições técnicas e temporais existentes noprojeto.

1.1 Âmbito do Projeto

Este documento tem como objetivo apresentar o projeto de desenvolvimento daaplicação e-Litter, que permitirá a manutenção informatizada dos dados das coletas demateriais orgânicos realizadas em pesquisas do Departamento de Biologia da UFS e ageração de relatórios e gráficos descritivos do ambiente estudado.

A principal cliente será a profª Myrna Landim, do Departamento de Biologia daUniversidade Federal de Sergipe, que realiza pesquisas referentes ao material orgânicoproduzido pela vegetação de mangue. Além do projeto relacionado a mangues, existemoutros, realizados em tipos de ambientes diferentes, como a mata atlântica.

Os dados das coletas realizadas são organizados e totalizados para que possam serfeitas análises estatísticas do depósito de serapilheira (material orgânico) ao decorrer deum período, que geralmente é de um ano. Essa análise é feita através de tabelas com atotalizaçã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 algunsdados (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 outrosparticipantes definidos por eles deverão ter acesso aos dados, assim como podermodificá-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émdeve ser mantida a consistência entre os dados cadastrados e aqueles apresentados aousuário.

O sistema também deve ser de fácil manutenção e evolução do conjunto defuncionalidades. Tem que ter uma interface rica e de fácil aprendizagem e utilização.

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

1

O sistema deverá ser desenvolvido utilizando apenas ferramentas em plataformasgratuitas. O projeto só poderá contar com 2 desenvolvedores, que cumprirão tambémtodos 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 desempenhodos participantes no projeto, a duração das tarefas, as fases e os requisitos que temosde definir e outros tópicos essenciais. Alguns desses requisitos exigem um cálculointuitivo da sua duração, porém pode ser que nem sempre esta estimativa estejacorreta, 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 maiorpercepção da longevidade que o projeto terá, ou seja o tempo total do projeto. Por suavez também pode efetuar os cálculos necessários para determinar o tempo de cada fasedo 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 elementoda equipe contém experiência na realização de projetos de software, exceto porexperiê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 totalde duração do projeto (em dias). E para encontrar esse tempo é necessário aplicar umaté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 sersimples e fácil de utilizar. Podemos então mencionar a definição de métrica para que nãorestem duvidas do que é uma métrica: “Medida quantitativa do grau de posse de umatributo 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 tipode 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 demultiplicação

3. Multiplicar a quantidade de classes-chave pelo Multiplicador para obter umaestimativa do número de classes de suporte

2

4. Em seguida, calcula-se a quantidade total de Classes, somando o nº de Classes-Chavecom 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 sugereentre 15 e 20 dias-pessoa por classe. Escolher um número entre 15-20 dias-pessoa ejustificar 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 resultadosseguintes:

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) porclasse onde a métrica Lorenz & Kidd sugere entre 15 e 20 dias-pessoa por classe. Emconjunto optamos por escolher 16 dias-pessoa devido ao fato de estarmos familiarizadoscom as nossas ferramentas de trabalho, como por exemplo o “Eclipse”, o “PostgreSQL”,"Microsoft Project 2003", "StarUML" e a linguagem "Java", em relação a deixar as coisaspara fazer para última hora até que não é o nosso lema de trabalho, mas às vezes, comoexistem outros trabalhos paralelamente, nem sempre é possível fazer tudo comopretendí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 naequipe, para dividir os 1216 dias de trabalho, ficaremos com aproximadamente 608 diasde 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 dividirpelos os 22 dias úteis.

608 X 30 = 18240 / 22 = 829,09 ~ 829 dias corridos829 / 30 = 27,63 ~ 27 Meses corridos

Sabendo-se os dias de trabalho totais (608 dias), estes dias são agora distribuídos deacordo com as seguintes percentagens de distribuição dos componentes essenciais numprojeto:

1) Planejamento: 2-3%2) Requisitos – Análise – Desenho: 40%3) Geração de Código: 20%4) Testes: 37-38%

3

Os valores calculados são:

1) Planejamento: 608 * 3% = 18 dias de trabalho2) Requisitos – Análise – Desenho: 608 * 40% = 243 dias de trabalho3) Geração de código: 608 * 20% = 122 dias de trabalho4) 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, osrecursos 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 SoftwareRubens 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 taisconhecimentos 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 determinadosriscos que não podem ser ignorados, antes pelo contrário, devemser alvos de uma exaustiva análise e há que saber geri-los de forma a tentar evitá-los ouminimizá-los.

3.1 Riscos do projeto

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

4

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 confiabilidaderequerida

X X

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 melhorviabilidade 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 acompetê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çocomplementar para cada um.

3.2 Tabela de riscos

Na tabela 3 encontram-se descritos todos os riscos identificados no projeto. Os riscosestão enumerados da seguinte forma, na primeira coluna encontra-se a descrição do

5

risco, na segunda coluna a categoria do risco, na terceira a probabilidade de o riscoacontecer 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 riscosrelacionados anteriormente: Âmbito instável, Falta de formação nas ferramentas eExtravio 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 seremutilizadas

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 comfreqüência.

Estratégia de redução: Fixar com o cliente uma prazo para adição de novasfuncionalidades.

6

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 osresponsáveis pelas tarefas, este processo designa-se Diagrama de Gantt, cujaresponsabilidade 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 aocliente e obter o feedback necessário para as melhorias e correções. Este modelo foi oque mostrou-se mais adequado às circunstâncias, devido a este projeto ser umacontinuação de um anterior, no qual a maioria das funcionalidades já haviam sidoimplementadas, parcial ou completamente.

Após ter sido feita a Estimação do Projeto, a divisão do plano de tarefas pelapercentagem 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ãode funções não restritiva. Isto significa que apesar de haver responsabilidadesespecíficas para cada um, as atividades são desenvolvidas de forma colaborativa, a fimde agilizar ao máximo o trabalho.

7

5.1 Estrutura da equipe

Os 2 integrantes da equipe são:

Rafael de Mendonça França - Gerente de Projeto e Programador de SoftwareRubens Matos - Analista de Sistema e Testador de Software

O Gerente de Projeto tem a responsabilidade de coordenar todo o desenvolvimentodo projeto, combinando reuniões, distribuindo tarefas. Ele é responsável peloplanejamento temporal do projeto, elaborando o diagrama de Gantt e algumas outraspossíveis formas de delineamento das ações a serem executadas.

O Analista de Sistema deve fazer o levantamento de requisitos e a análise dosoftware, assim como elaborar diagramas do sistema e estabelecer quais classes einterfaces 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 dadisciplina, de maneira presencial, e também em outros horários disponíveis para osmembros, através de correio eletrônico, softwares de mensagens instantâneas, comoMSN Messenger e GTalk, e anotações no Google Docs, onde os documentos sãoelaborados colaborativamente. As formas de comunicação eletrônica foram defundamental importância, devido a incompatibilidades de horários dos integrantes daequipe e a dificuldade em cumprir todas as atividades dentro do tempo das aulasprá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 dedisponibilizar os documentos produzidos durante o projeto. Devido a exisitirem somente2 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 dediferenças entre versões, caso fossem usados os blogs dos dois integrantes. A utilizaçãode outras ferramentas de comunicação também foi um motivo para que não criássemosum blog exclusivo para a equipe.

6 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DOPRODUTO DE SW

Para assegurar e controlar a qualidade do produto de Software, é necessário terdiversos cuidados, segue-se assim uma descrição de todas as medidas tomadas paraassegurar a qualidade dos produtos de software desenvolvidos pela equipe:

• Acompanhamento e Controle do Projeto de SW – Acompanhamento contínuo dotrabalho desenvolvido por parte de todos os participantes no projeto.

• Produção de Documentação – Elaboração de documentos em relação ao plano doprojeto e às especificações do produto.

• Gestão de Reutilização – Preocupação por parte do programador de implementarcódigo reutilizável, assim como do analista de elaborar classes que facilitemessa tarefa.

8

• Análise de Riscos – Identificação de todos os riscos inerentes ao projeto eelaborar os planos de redução e de contingência.

• Testes – Execução exaustiva de teste do sistema com o objetivo de identificarpossíveis erros antes que estes se transformem em defeitos.

9