Universidade Federal de Sergipe
       Departamento de Computação
   Bacharelado em Ciência da Computação
Disciplina: Tópi...
1 INTRODUÇÃO

   Esta seção descreve uma visão geral sobre o projeto de software, iniciando com uma
descrição do seu âmbit...
O sistema deverá ser desenvolvido utilizando apenas ferramentas em plataformas
gratuitas. O projeto só poderá contar com 2...
4. Em seguida, calcula-se a quantidade total de Classes, somando o nº de Classes-Chave
com o nº de Classes de Suporte.
5. ...
Os valores calculados são:

1)   Planejamento: 608 * 3% = 18 dias de trabalho
2)   Requisitos – Análise – Desenho: 608 * 4...
Risco                       Projecto Técnico Negócio Comum Especial
Equipamento não disponível                            ...
risco, na segunda coluna a categoria do risco, na terceira a probabilidade de o risco
acontecer e na quarta o tamanho de i...
Plano de contingência: Negociar com o cliente aumentos de prazo e retorno financeiro.
Pessoa responsável: Rubens de Souza
...
5.1 Estrutura da equipe


   Os 2 integrantes da equipe são:

       Rafael de Mendonça França - Gerente de Projeto e Prog...
• Análise de Riscos – Identificação de todos os riscos inerentes ao projeto e
  elaborar os planos de redução e de conting...
Upcoming SlideShare
Loading in...5
×

Plano do Projeto

2,418

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,418
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
121
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Plano do Projeto

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×