Plano de projeto de software

2
SUMÁRIO
1.0 INTRODUÇÃO.............................................................................................................. 3
1.1 DESCRIÇÃO DO PROJETO.................................................................................... 3
1.2 PRINCIPAISFUNÇÕESDO SISTEMA..................................................................... 3
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 ESTIMATIVA........................................................................ 4
2.3 RESULTADOS..................................................................................................... 5
2.4 RECURSOS DO PROJETO..................................................................................... 5
2.5 DIAGRAMA DE GANTT....................................................................................... 7
3.0 ANALISE E GESTÃODE 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ÇÃODO PESSOAL....................................................................................... 11
4.1 ESTRUTURA DA EQUIPE..................................................................................... 11
4.2 MECANISMOSDE COMUNICAÇÃO..................................................................... 12
4.3 USO DO EDU-BLOG COMO FERRAMENTA DE APOIO.......................................... 12

3
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
ensinoe 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 gestorentracom os editais e oscalendáriosde execuçãodosprojetos,issodeve serdefinido
nos perfisde cada usuário que faz login no sistema. Os professores e técnicos entram com as
solicitaçõesde suasatividadesde extensãoe osestudantesfazem 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 professoresou 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çãode atividadescasoestes 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
muitasfuncionalidadesestãosendomudadastantonaUFS quantona 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.

4
2.0 ESTIMATIVAS DO PROJETO
Esta seçãomostrará as estimativasde custo,esforçose 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(emdias).Foi utilizadaamétricade Lorenz& Kidd,aconselhadapelaLacertae Software
para estimar o prazo total deste projeto.
2.2.1 TECNICAS DE ESTIMATIVA
Foi utilizadaatécnicade estimativadoCPDUFS Produçãode Software Ltdaque é 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. Definironúmerode classeschave;
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. Multiplicara quantidade de classes-chavepeloMultiplicadorparaobteruma
estimativadonúmerode classesde suporte;
4. Logo após,calcula-se aquantidade total de Classes,somandoonºde Classes-Chave
com o nº de Classesde Suporte;
5. Multiplicaraquantidade total de Classes(classes-chave +classesde suporte) pelo
“númeromédiode unidadesde trabalho(dias-pessoa) porclasse”.Lorenz&Kidd
sugere entre 15 e 20 dias-pessoaporclasse.Escolherumnúmeroentre 15-20 dias-
pessoae justificaraescolha.
6. Determinaraquantidade de esforçoestimada;
7. Calculo do tempo previsto para a elaboração do projeto.
A tabelaabaixomostraosfatores 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

5
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. Comona empresanãotenhoexperiênciaparasaberexatamente aquantidadede 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,fazendoamultiplicaçãodosdiasde trabalhocom os 30 diasdo mêse 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 recursosusadospara elaboraçãodeste projetoserão:humanos,de software,hardware e
bibliográficos.
Em relaçãoaos recursoshumanos,comoesse 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çãoserácolocadacomo um dosprofissionaisresponsáveispelo sistema e aparecerá no
diagrama de Gantt.

6
Recursos humanos:
A equipe de desenvolvimentodoprojetoé formadapor quatromembros,sãoeles:
UFRN
· Gestorde Projeto
· Analistade sistemas
SigelmanAraujo
· Gestorde Projeto
· Analistade sistemas
DiegoCortes
· Analistade Sistemas
· Programadorde Software
· Engenheirode Software
Vinicius
· Programadorde Software
Carla Cássia
· Testadorade Software
Recursos de Software:
Para o desenvolvimentodeste projetoforamutilizadasas 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,sistemade gerênciade bancode 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 hardwaresutilizadosparaelaboraçãodoprojetosão:
· ComputadoresPessoaisPCdaHP
· Impressoraparatestesde impressão
Recursos Bibliográficos:
O recursobibliográficoutilizadofoi oque segue:
PRESSMAN,RogerS. Engenhariade Software,6ªedição,SãoPaulo,McGraw-Hill,2006

7
2.5 DIAGRAMA DE GANTT
O diagramade Gantt é ilustrado a seguir,trata-se de umgráficoque mostra todasas tarefas
planejadascomsuasdatas de inicioe fime os recursosutilizados.
Imagem do diagrama de Gantt parte 1
Imagem do diagrama de Gantt parte 2

8
3.0 ANÁLISE E GESTÃODE 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 umsubconjuntode riscosque estãopresentesem qualquer projeto de software, riscos
gerais, que são indicados na tabela seguinte:
Risco Projeto Técnico Negócio Comum Especial
Equipamento não disponivel X
Requisitos incompletos X X
Uso de metodologias especiais X X
Problemas na busca da
confiabilidade requerida
X X
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 clientesaofazeremtreinamentosnasversõescolocadas 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,
faltandoapenasanalisarse 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 possoafirmaremrelaçãoa UFRN,porémemrelaçã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 nastabelas 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.

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

10
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

11
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 nossaequipe segue umaestruturadescentralizada democrática, pois, apesar de termos um
gestorcompetente responsável pela organização dos trabalhos, as decisões são tomadas em
conjuntoe com o consensode todose a comunicaçãoé horizontal.Alémdisso,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 é formadaporcincoelementose 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 noseiodogrupo,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 engenheirode software estudae selecionatantoasferramentasutilizadascomoohardware
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.

12
4.2 MECANISMOS DE COMUNICAÇÃO
A comunicaçãoentre todososelementosdaequipeé feitaprincipalmenteatravésde reuniões
periódicas, resolvem-se problemas em conjunto e distribuem-se tarefas. Além disso, são
tambémutilizadososmeios 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
Achamoso Edu-bloguma 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çãoaos blogsde cada equipe,achamosque é tambéminteressante 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.

Plano de projeto de software

Mais conteúdo relacionado

Mais procurados

Semelhante a Plano de projeto de software

Plano de projeto de software