UNIVERSIDADEFEDERALDESERGIPE

CENTRODECINCIASEXATASETECNOLOGIA
DEPARTAMENTODECOMPUTAO
ProgramadePsGraduaoemCinciadaComputao
EngenhariadeSoftware2014.1






PLANODEPROJETODESOFTWAREOO
paraprodutosdaLacertaeSW

DiegoArmandodeOliveiraMeneses201411005115

JislaneSilvaSantosMenezes201411006248

ThiagoCoutodeAlmeida201411004833

SoCristvo

2014

1
 UNIVERSIDADEFEDERALDESERGIPE
CENTRODECINCIASEXATASETECNOLOGIA
DEPARTAMENTODECOMPUTAO
ProgramadePsGraduaoemCinciadaComputao
EngenhariadeSoftware2014.1










PLANODEPROJETODESOFTWAREOO
paraprodutosdaLacertaeSW






DiegoArmandodeOliveiraMeneses201411005115

JislaneSilvaSantosMenezes201411006248

ThiagoCoutodeAlmeida201411004833

Trabalho realizado no mdulo de

Gesto de Projetos ministrado
pelo Prof. Dr. Rogrio Patrcio
Chagas do Nascimento na
disciplina de Engenharia de
Software da PsGraduao em
Cincia da Computao da
Universidade Federal de Sergipe
(UFS).

SoCristvo

2014

2
 Sumrio

1 INTRODUO......................................................................................................................5
1.1 mbitodoprojeto.......................................................................................................5
1.2 Funesprincipaisdoprodutodesoftware...............................................................6
1.3 Requisitoscomportamentaisoudeperformance......................................................7
1.4 Gestoerestriestcnicas.....................................................................................7
2 ESTIMATIVADOPROJETO..............................................................................................8
2.1 Dadoshistricosutilizadosparaasestimativas........................................................8
2.2 Tcnicasdeestimativaeresultados..........................................................................8
2.3 Resultados..................................................................................................................9
2.4 Recursodoprojeto....................................................................................................10
2.4.1 Recursoshumanos..............................................................................................10
2.4.2 Recursosdesoftware.........................................................................................10
2.4.3 Recursosdehardware........................................................................................11
3 ANLISEEGESTODERISCOS...................................................................................12
3.1 Riscosdoprojeto......................................................................................................12
3.2 Tabeladeriscos........................................................................................................14
3.3 Reduoegestoderiscos......................................................................................16
4 PLANEJAMENTOTEMPORAL.......................................................................................20
4.1 Conjuntodetarefasdoprojeto.................................................................................20
4.2 DiagramadeGantt...................................................................................................21
5 ORGANIZAOPESSOAL...............................................................................................24
5.1 Estruturadaequipe..................................................................................................24
5.2 Mecanismosdecomunicao..................................................................................25
5.3 UsodoEdublogcomoferramentadeapoio...........................................................25
6 PRECAUESTOMADASPARAASSEGURARECONTROLARAQUALIDADE
DOPRODUTODESW.....................................................................................................25

3

SUMRIODASFIGURAS
Figura1:DiagramadeCasodeUso...6
Figura2:CronogramaResumidodoProjeto(DiagramadeGantt)..22
Figura3:CronogramaDetalhadodoProjeto(DiagramadeGantt).22
Figura4:CronogramaDetalhadodoProjetoContinuao(DiagramadeGantt).23
Figura5:DiagramadeGanttdoProjeto...23
Figura5:DiagramadeGanttdoProjetoContinuao..24

SUMRIODASTABELAS
Tabela1:DescriodoProblema..5
Tabela2:EscopoGeral..5
Tabela3:DescrioDetalhadadoCasodeUso..6
Tabela4:FatoresMultiplicativosparaObteroNmerodeClassesdeSuporte..9
Tabela5:RiscosGeraisdoProjeto....13
Tabela6:CategorizaodosRiscosdoProjeto.....14
Tabela7:Distribuioemdiasdasfasesdoprojeto..21

4
1INTRODUO

1.1mbitodoprojeto

O sistema de remoo de servidores um software para gerenciamento de remoo interna de

funcionrios de uma determinada instituio pblica de ensino. O objetivo principal deste software
construir uma fila de espera por cargo, baseada em critrios definidos pela administrao. Desta forma,
cada servidor poder manifestar sua inteno de ser removido para uma outra localidade (campus da
instituio no estado), possibilitando que a administrao possa realocar seus funcionrios de maneira
clereetransparente.

Gerenciarasremoesinternasdosservidoresentreoscampusdainstituio.
Problema Faltadetransparnciaeceleridadedoprocessoderemoo.
Burocraciaecomplexidadeparamanifestarinteresseemremoo.
Usurios ServidoresAtivos(Docentesetcnicosadministrativos).
Afetados
Melhorgerenciamentodasfilasdeespera.
Funcionamento
Maiortransparnciaeceleridadeaoprocessoderemoo.
Ideal
Simplificaodoprocessodepedidoderemoo.

Tabela1DescriodoProblema

Inserodevagas.
Entradas
Manifestaodopedidodeinteresse.
Ordenaodafiladeesperacombasenoscritriosdefinidos.
Informaraoservidor(prioritrio)apossibilidadederemoo.
Processamento
Confirmaodointeressedoservidoremserremovido.
Confirmaodaadministraodopedidodaremoo.
Sada Aremooefetivaemumprocessotransparenteeclere.

Tabela2EscopoGeral

5
1.2Funesprincipaisdoprodutodesoftware

O diagrama de caso de uso exibido na Figura1,descrevedeformavisualos principaisusuriose
funcionalidades do software, na Tabela 3 descrevemos de forma sucinta as atividades eseusrespectivos
atores.

Figura1.DiagramadeCasodeUso

Atores Funcionalidades
Administrao Manterconfiguraesdosoftware(Insero,Excluso,AlteraoeConsulta).
(Especializao do Mantereditalderemoo(Insero,Excluso,AlteraoeConsulta).
atorservidor) Mantervagaderemoo(Insero,Excluso,AlteraoeConsulta).
Confirmaodaremooperanteconformidadeaoscritriosestabelecidos.
Servidor Consultar fila de interesses cadastradas (fila de interesse ordenadadeacordocom
oscritriosinformadospelaadministrao).
Manterinteressenaremoo(Insero,Excluso,AlteraoeConsulta).
Consultarvagasderemoocadastradas.
Confirmarinteressederemoosolicitada.

Tabela3DescriodetalhadadoCasodeUso

6
1.3Requisitoscomportamentaisoudeperformance

Reduziraprobabilidadedeindisponibilidadedoacessoaosistema.
Minimizaraprobabilidadedecorrupodedados
Observao dos padres e regras estabelecidas garantindo a transparncia e corretude do
processo.
Seguranadeacesso,permitindoacessosomenteaosservidoreshabilitados.
Facilidadeparaoperaroproduto.
Minimizar o esforo para realizar alteraes, remover falhas e/ou adequar o produto a eventuais
mudanasdeambiente.

1.4Gestoerestriestcnicas

AseguirserolistadosalgumasrestriestcnicasdoSistemadeRemoo:

Osistemanecessitaserdesenvolvidoutilizandoarquiteturaweb.
OsistemanecessitaserdesenvolvidoutilizandoalinguagemJAVAutilizandooframeworkJSF.
OsistemadeveutilizaroPostgreSQLcomobancodedados.
OsistemadeveutilizaroSubversioncomocontroladordeverso.
Oacessoaosistemadeveserfeitoporumnavegadorweb.

7
2ESTIMATIVADOPROJETO

Segundo PRESSMAN(2006), o clculo das estimativas uma das atividades fundamentais do

processo de gerenciamento de projetos de software. Nesta etapa realizadooplanejamentodoesforo
humano, o custo e da durao cronolgica do projeto. Estimativas so baseadasemmtricashistricase
empricas.
Osobjetivosdeutilizaodasmtricaseestimativasso:
Entenderocomportamentoefuncionamentodoprodutodesoftware
Avaliarospadres,metasecritriosdeaceitao
Controlarprocessosprodutoseservios
Prevervaloresdeatributos

Ousocorretodasmtricaseestimativastrazalgunsbenefcioscomo:
Indicarqualidadedoproduto
Formarbasededadosparaoutrosprojetos
Avaliarprodutividade
Ajudarnatomadadedecisesestratgicas

2.1Dadoshistricosutilizadosparaasestimativas

A instituio que executar o projeto no possui um histrico de elaborao de produtos de

software.Nosendopossvelestabelecercomparaeseestimativasbaseadasemumhistrico.

2.2Tcnicasdeestimativaeresultado

Nesta seo demonstrase como foi efetuado o clculo para estimar a durao do projeto (em
dias). Para aferiressetempoutilizouseamtricadeLorenz&Kidd(1994).A mtricadeLorenz&Kidd
compostadospassosdescritosaseguir:
1.Definironmerodeclasseschave.
2. Encontrar o nmero de classes de suporte necessrio classificar o tipo da interface do
produto e desenvolver um multiplicador para as classes de suporte (os multiplicadores so apresentados
naTabela4).

8
 3. Multiplicar a quantidadedeclasseschavepelomultiplicadorobtendoumaestimativadonmero
declassesdesuporte.
4. Calcular a quantidade total de classes, somando o nmero de classes chave com o nmerode
classesdesuporte.
5. Multiplicar a quantidade total declasses(obtidasnoitem4)pelonmeromdiodeunidadesde
trabalho(diaspessoa)porclasse.Amtricasugereentre15e20dias.
6.Determinaraquantidadedeesforoestimada.
7.Calcularotempoprevistoparaaelaboraodoprojeto.

Interface Multiplicador

Nogrfica 2

Baseadaemtextos 2,25

GUI 2,5

GUIcomplexa 3

Tabela4Fatoresmultiplicativosparaobteronmerodeclassesdesuporte

2.3Resultados

UtilizandoamtricadeLorenzeKidd(1994)descritanoitemanterior,obtemososseguintes
valores:

1.NmerodeClassesPrincipais:
4classes:Servidor,Vaga,InteresseeConfiguraes.
2.Definiodomultiplicador:
ComoainterfaceforaclassificadacomoGUI,temoscomo2,5fatormultiplicador(ver
tabela4).
3.Nmerodeclassesdesuporte:
NClasseschaveXmultiplicador=4X2.5=10classesdesuporte.
4.Nmerototaldeclasses:
NClassesChave+NClassesdeSuporte=4+10=14classes.
5.Definiodonmeromdiodeunidadesdetrabalho:

9
 Definiusequeaunidadedetrabalhoserde20diaspessoajquenohumhistrico
pararealizaodeestimativas.
6.Determinaodaquantidadedeesforoestimada.
NTotaldeClassesXUnidadesdetrabalho=14X20=280dias.

7.Clculodotempoprevistoparaaelaboraodoprojeto.
Primeiroobtemosaquantidadedediascorridosatravsdoseguinteclculo:
Diascorridos=DiasestimadosX(diasporms/diasteisporms).Dessaforma,temos:
Diascorridos=280X(30/22)=8400/22=381,81=382.
Paraobteraquantidadedemesescorridospodemosaplicaroclculoabaixo:
Mesescorridos=Diascorridos/diasporms
Mesescorridos=381,81/30=12,72=13.
Como teremos 3 pessoas envolvidas em todas as fases do projeto podemos dividir o
nmerototaldediaspelaquantidadedepessoasenvolvidas.
Dias=382/3=127,33=128dias
Tomando por base que o projeto ser construdo utilizando a metodologia de
desenvolvimento iterativo e incremental e que o projeto ser executado em dois ciclos,definiuse
queparaoprimeirocicloseronecessrios78diasenosegundocicloserproduzidoem50dias.

2.4Recursosdeprojeto

2.4.1Recursoshumanos

Aequipecompostaportrsmembrosqueestoenvolvidosemtodasasfasesdoprojeto.

2.4.2Recursosdesoftware

Os recursos de software utilizados no projeto so ferramentas de conhecimento pblico

amplamente utilizadas nacomunidade,nenhumdelesrequerumalicenaespecficaparasuautilizao.So
eles:
Subversion(controladordeverso)
TortoiseSVN1.8.5.25224x64svn1.8.8(clientedoSubversion)
Apache/Tomcat7.x(servidordeaplicao)

10
 StarUML5.0(ferramentaparaelaboraodediagramasUML)
DBDesigner4(ferramentaparaelaboraoDER)
jdk7u51windowsx64(mquinavirtualJAVA)
netbeans7.4javaeewindows(IDEdedesenvolvimento)
primefaces4.0(bibliotecadecomponentesdoJSF)
primefaces4.0sources(sourcesdoPrimeFaces)
PostgreSQL8.4(Bancodedados)
pgAdmin(clientedoPostgreSQL)
postgresql9.1.112windowsx64(driverparaacessoaobancodedados)
OpenProj1.4(ferramentaparaelaboraodogrficodeGantt)

2.4.3Recursosdehardware

Osrecursosdehardwareexigidospelaaplicaosoamplamenteatendidospelainstituio.
Computadorespessoaisparacadamembrodaequipeemredelocal
Servidordedesenvolvimentovirtualizado
Servidordetreinamentovirtualizado
Servidordeproduovirtualizado.

11
3ANLISEEGESTODERISCOS

Os riscos so problemas em potencial que podem ou no, vir a seconcretizar.Em PRESSMAN

(2006) encontramos trs fundamentos conceituais que definem o risco: o futuro, as modificaes e que
mtodos e ferramentas devem ser utilizados. O futuro imprevisvel, assim difcil prever que riscos
podem causar o insucesso do projeto de software. As modificaes nos requisitos, ou em outros
aspectos relacionados ao projeto como tecnologia de desenvolvimento e suporte podem resultar em
atrasos de cronograma e porconseguinteoinsucessodoprojeto.Quantoaosmtodoseferramentas,que
procedimentosdequalidadedevemseraplicadosduranteoprojeto.
A fim de minimizar os riscos, necessrio gerencilos. Segundo o PMBOK(2008), o
gerenciamento de riscos do projeto inclui os processos relacionados com o planejamento, identificao,
anlise, elaborao de respostas, monitoramento e controle dos riscos em um projeto. Esta fase
conhecida por anlise e gesto de risco que so aes que auxiliam uma equipe de software a
compreenderegerenciarasincertezasdonegcio.
Algunspassosdevemserrealizadosparagerenciaressesriscos,soeles:

Identificarosriscos
Avaliarprobabilidadedeocorrncia
Estimaroimpacto
Estabeleceroplanodecontingncia

Os trs primeiros passos resultam na tabela dos riscos do projeto, abordados na seo 3.2. O
planodecontingnciaserabordadonaseo3.3.
Os envolvidos nesta etapa so todos aqueles que fazem partedagestodequalidadedoproduto
(Gerentes, Engenheiros de Software, Stakeholders). importante a utilizao da gesto de riscos, pois
alguns riscos, se concretizados podem vir a suspender o processo de produo do produto
(PRESSMAN,2006).

3.1Riscosdoprojeto

Alguns riscos esto sempre presentes em quaisquer projeto de software, eles podem ser
consideradosriscosgeraisesolistadosnaTabela5.

12


Risco Projeto Tcnico Negcio Comum Especial

Equipamentonodisponvel X

Requisitosincompletos X X

Usodemetodologiasespeciais X X

Problemas na busca da confiabilidade X X

requerida

Retenodepessoaschaves X X

Subestimativasdeesforo X X

Tabela5Riscosgeraisdoprojeto

AvaliaoGlobaldoRisco:

1.OGestordeSoftwaredsuporteaoprojeto?
Sim. O gestor estar responsvel por garantir o alcance do sucesso do produto de software,
participandoeinformandoaosinteressadossobreoandamentodoprojeto.

2.OsClientesestoentusiasmadoscomoproduto?
Sim. Pois a implantao do produto trartransparnciaepublicidadeaoprocessodeseleodos
concursosderemoointerna.

3.OsEngenheirosdeSoftwarecompreenderambemosrequisitos?
Sim. Os engenheiros tem acesso aos requisitos legais (critrios definidos pela gesto do rgo)
quedeterminamosparmetrosqueinfluenciamnaseleo.

4.OsClientesestiveramenvolvidosnadefiniodosrequisitos?
Sim.Osclientesexpuseramdemaneiraformalquaisosprincipaisrequisitosnecessriospara
construiraaplicao.

5.Ombitodoprojetoestvel?
No.Oescopodoprojetovariveljqueosrequisitoslegaispodemseralterados.

13
6.OsengenheirosdeSoftwaretmascompetnciasrequeridas?
Sim.Osgerentessoqualificadosparaasatividadesquelhessopropostas.

7.Osrequisitosdoprojetosoestveis?
No.Comooinstitutotemautoridadepararegeroscritriosdeseleopararemoointerna,a
influnciadagestoquemgaranteaestabilidade.

8.AEquipedeDesenvolvimentotemexperincianatecnologiaqueserutilizada?
Sim.Aequipededesenvolvimentopossuiexperinciaacadmicanastecnologiasqueestosendo
utilizadas.

9.adequadoonmerodepessoasdaequipedetrabalho?
Nopossvelpreverestequesitojquenohumhistricodedesenvolvimentodeprojetos
pelaequipe.

3.2Tabeladeriscos

A tabela de riscos contm os riscos identificados no projeto,dispostosemordemdecrescentede

probabilidade e impacto (PRESSMAN,2006). A Tabela 4 identifica para cada risco a sua categoria,
probabilidade de ocorrncia e impactosobreoprojetoemcasodeconcretizao.Foramidentificados20
riscosemdiferentescategorias.ListadosnaTabela6.

N Risco Categoria Probabilidade Impacto

1 Greve
Pessoal 85% Crtico

2 Influnciaderestriesgovernamentais
associadaalegislaoquedefineonegcio
Negcio 80% Catastrfico

3 Requisitosdoprojetoinstveis
Negcio 80% Catastrfico

4 Usodenovastecnologias
Tecnologia 80% Crtico

14
5 Escopodoprojetoinstvel
Tamanho 75% Catastrfico

Altavisibilidade(expectativa)donmerode
6 clientesqueusarooproduto Negcio 75% Crtico

7 Noutilizaoderevisestcnicaformais
Processo 75% Crtico

8 Descomprometimentodaaltaadministrao
comodesenvolvimentodoprojeto
Negcio 60% Crtico

9 Prazosetempoparatarefasmalestimados
riscodeprojeto Negcio 60% Crtico

10 Restriesdeinteroperabilidadecomo
sistemadeRH Negcio 50% Catastrfico

11 Faltadeexperinciadaequipenatecnologia
Pessoal 50% Marginal

12 Mauusodasferramentasdeauxlioa
construodosoftware Ambiente 35% Marginal

13 Imprevistosdepessoal
Pessoal 30% Crtico

14 UsoincorretodeferramentasCASEpara
anlise,designeteste
Processo 20% Crtico

15 Nmerodeusuriodoproduto(crescimento
donmerodeusurios)
Tamanho 20% Marginal

16 Porcentagemdecrescimentodabasede
dados Tamanho 20% Marginal

17 Impactosnooramentodaempresa
InstituioPblica Negcio 15% Crtico

18 Volatilidadedopessoaldaequipe Pessoal 15% Crtico

15
19 Colaboradoresdoprojetosotambm
clientesdoproduto Pessoal 15% Marginal

20 Descontinuaodeferramentasdeauxlioa
construodesoftware
Ambiente 10% Desprezvel



Tabela6CategorizaodosRiscosdoProjeto

3.3Reduoegestoderiscos

O Plano de Reduo, superviso e gesto do risco (RSGR) desenvolvido para ser utilizado
quando um risco de fato se concretiza, ou seja, quando os planos de preveno ao risco falharam ou
quandoosriscostemprobabilidadeeminentedeacontecer.
Para identificar quais os riscos queterooplanodecontingncia(RSGR)estabelecido, utilizouse
a mtrica Categoria/Probabilidade, onde o ponto de corte:riscoscomcategoria(CatastrficoeCrtico)
igual ou acima de 50% de probabilidade de ocorrncia (Os riscos que se aplicam a essa mtrica foram
destacadosemvermelhonatabeladeriscos).

Greve

Risco1 Probabilidade:85% Impacto:Crtico

Descrio: Greve dos servidores ativos da instituiopblica(Docentese/ou tcnicosadministrativos)

durante todo ou parte do perodo estabelecido para o projeto. Obs: esse risco foi classificado com
uma alta probabilidade porque na instituio de ensino que usamos como escopo h uma indicao
muito forte de greve, onde essa indicao ser aprovada ou no no dia 29/04.
http://www.sinasefe.org.br/v3/index.php/noticiasdagreve/991grevedosinasefecomecahoje

Estratgia de reduo: No existe estratgia de reduo. As greves em instituies pblicas onde

seus servidores ativos trabalham sobre um regime estatutrio esto fora do escopo da gerncia
projetos,ouseja,ogerentedeprojetosnotemcompetnciasobreessadeciso.

Planodecontingncia:Alterarocronogramaerenegociaroprazodeentregadoproduto.
Contratarequipeterceirizadaquenofaapartedosservidoresativos.

Pessoaresponsvel:ThiagoCoutodeAlmeida(criao16/04/2014)

Status:Situaocompletada(22/04/2014)

16


Influnciaderestriesgovernamentaisassociadaalegislaoquedefineonegcio

Risco2 Probabilidade:80% Impacto:Catastrfico

Descrio: Critrios que norteiam aremoodosservidorespodemsercriados ealteradosatravs

normativas do Ministrio do Planejamento, Oramento e Gesto (MPOG), tirando a autonomia
institutoemestabelecercritriosprpriosparaordenarafiladeinteresses.

Estratgia de reduo: Avaliao da legislao no que se refere a remoo de servidores

administraopblica.

Planodecontingncia:Reavaliarrequisitosfuncionaisdoprojeto.Negociarnovosprazos.

Pessoaresponsvel:ThiagoCoutodeAlmeida(criao08/04/2014)

Status:Situaocompletada(14/04/2014)

Requisitosdoprojetoinstvel

Risco3 Probabilidade:80% Impacto:Catastrfico

Descrio: Requisitos do projeto instvel. As mudanas de requisitos durante o desenvolvimento

projeto podem impactar significativamente o andamento do mesmo, podendolevar atasuspeno
projeto.

Estratgia de reduo: Proporcionar reunies peridicas de conscientizao dos benefcios

implantaodoprodutodesoftware.

Plano de contingncia: Realizar a redefinio do escopo, alterar o cronograma e renegociar o prazo

deentregadoproduto.

Pessoaresponsvel:ThiagoCoutodeAlmeida(criao15/04/2014)

Status:Situaocompletada(18/04/2014)

Usodenovastecnologias

Risco4 Probabilidade:80% Impacto:Crtico

Descrio: A equipe do projeto no possui experincia nas tecnologiasusadasparaanlise,projeto

desenvolvimento do produto de software, essa falta de conhecimento pode acarretar em atrasos
cronograma, isso acontece por causa do tempo estendido para se realizar as tarefas nas novas

17
 ferramentas(Curvadeaprendizadomuitogrande).

Estratgia de reduo: Treinar a equipe de desenvolvimento nas novas tecnologias antesdeiniciar

projeto.

Planodecontingncia:Alterarocronogramaerenegociaroprazodeentregadoproduto.

Pessoaresponsvel:ThiagoCoutodeAlmeida(criao16/04/2014)

Status:Situaocompletada(22/04/2014)

Escopodoprojetoinstvel

Risco5 Probabilidade:80% Impacto:Catastrfico

Descrio:Escopodoprojetoinstvel

Estratgia de reduo: A instabilidade do escopo depende da alterao dos critrios de remoo,

assim estas configuraes devem ser parametrizadas de forma que o produto seja pouco modificado.
Naocorrnciadealteraodoescopoaestratgiadividirasentregasdoprojeto.

Plano decontingncia:Realizararevisodoescopoeentregarmdulosparciaisdoprodutoatualizar
cronograma.

Pessoaresponsvel:ThiagoCoutodeAlmeida(criao15/04/2014)

Status:Situaocompletada(18/04/2014)

Altavisibilidade(expectativa)donmerodeclientesqueusarooproduto

Risco6 Probabilidade:75% Impacto:Crtico

Descrio: Este software ter como usurios uma grande parte dos servidores da instituio que
aguardamduranteanosaoportunidadedeconcorrerememumeditalderemoo.

Estratgia: Cumprir as metas estabelecidas no plano de projeto de software para que os prazos
sejamobedecidos.

Plano de contingncia: Reestabelecer novos prazos, e esclarecer aos usurios o porqu no

possvelentregarosoftwarenoprazosdeterminado.

Pessoaresponsvel:ThiagoCoutodeAlmeida(criao08/04/2014)

Status:Situaocompletada(14/04/2014)

18
 Noutilizaoderevisestcnicaformais

Risco7 Probabilidade:75% Impacto:Crtico

Descrio: A no utilizao de revises tcnicas formais torna o software final sem qualidade,
com a ausncia dessa tcnica no se consegue: descobrir erros de funes ou lgica, avaliar se
software esta em conformidade com os requisitos, garantir o uso dos padres prdefinidos,
uniformidade do software, apontar melhorias necessrias. A no utilizao de revises formais
causadapelafaltadeexperinciadaequipeemprojetosdesoftwaregerenciados.

Estratgia:Fazerumplanoparautilizaoderevisestcnicasconsolidadasnoprojeto.

Plano de contingncia: Revisar o projeto identificando as reas afetadas e corrigindo os problemas

comousoadequadodasrevisestcnicas.

Pessoaresponsvel:ThiagoCoutodeAlmeida(criao16/04/2014)

Status:Situaocompletada(2204/2014)

Descomprometimentodaaltaadministraocomodesenvolvimentodoprojeto

Risco8 Probabilidade:60% Impacto:Crtico

Descrio:Descomprometimentodaaltaadministraocomodesenvolvimentodoprojeto

Estratgiadereduo:Integrarosstakeholdersnasetapasdedesenvolvimentodoprojeto

Plano de contingncia: Proporcionar reunies peridicas de conscientizao dos benefcios

implantaodoprodutodesoftwareGerenciarasexpectativasdosinteressadosnoprojeto

Pessoaresponsvel:ThiagoCoutodeAlmeida(criao15/04/2014)

Status:Situaocompletada(18/04/2014)

Prazosetempoparatarefasmalestimados

Risco9 Probabilidade:60% Impacto:Crtico

Descrio:Prazosetempoparatarefasmalestimados

Estratgia de reduo: Utilizar tcnica do valor agregado para avaliar a conduo do projeto.
Realizarreuniesperidicasdeacompanhamentodestatusdoprojeto

19
 Plano de contingncia: Revisar escopo, atualizar cronograma e redistribuir as tarefas para a equipe
semprequenecessrio

Pessoaresponsvel:ThiagoCoutodeAlmeida(criao15/04/2014)

Status:Situaocompletada(18/04/2014)

RestriesdeinteroperabilidadecomosistemadeRH

Risco10 Probabilidade:50% Impacto:Catastrfico

Descrio: Os dados dos servidores so consultados no sistema de RH, se no existir

interoperabilidadeaprincipalfontededadosnoseracessvel.

Estratgia: Notificar a empresa contratada responsvel pelo sistema de RH, que qualquer alterao
que for ser realizada dever ser informada com antecedncia mnima de 15 dias e que a mesma
entregueadocumentaodaalteraorealizada.

Plano de contingncia: Alocar os esforos da equipe para reconstruir a integrao entre

softwares.

Pessoaresponsvel:ThiagoCoutodeAlmeida(criao08/04/2014)

Status:Situaocompletada(15/04/2014)

4.PLANEJAMENTOTEMPORAL

Etaparesponsvelpeloplanejamentotemporaldasatividadesdefinindoasdatasdeexecuodas
tarefaseospapisresponsveispelaexecuo.

4.1Conjuntodetarefasdoprojeto

A metodologia utilizada para planejar o projeto uma implementao do modelo interativo

incremental em conjunto com as fases de processo definidas pela Lacertae SW, acrescentando a este
modelo a fase de implantao e treinamento. Devido ao escopo do projeto e asnecessidadesdeentrega
de releases (verso funcional do software), o projeto foi dividido em 2 ciclos, ondeoprimeirociclopor
conter mais atividades importantes, demanda um tempo maior. O tempo estimado para o processo de
desenvolvimento do software foi de 382 dias corridos. A equipe destinada para o projeto possui 3
pessoas. Diante desta configurao a quantidade de dias necessrios para realizar o projeto foi reduzida

20
para128dias,divididosem2ciclos(1Ciclo:78diase2Ciclo:50dias).
A Tabela 7 mostra de formadetalhadaadistribuiodosdiasparacadafasedoprocesso,dentro
do seu ciclo, cada ciclo responsvel pela entrega de um release. Esta abordagem em 2 ciclos foi
planejada por causa da necessidade de avaliar o software em funcionamento com os usurios reais na
primeiraentrega.

Fase Porcentagem Durao(dias)1 Durao(dias)2

Ciclo Ciclo

Planejamento 3% 2,34 1,5

AnliseeProjeto 38% 29,64 19

Codificao 19% 14,82 9,5

Testes 37% 28,86 18.5

ImplantaoeTreinamento 3% 2,34 1,5

Tabela7Distribuioemdiasdasfasesdoprojeto

4.2DiagramadeGantt

O Diagrama de Ganttumaferramentaquepermiteatravs degrficosinformaroandamentodas

etapas do projeto. Sua facilidade de uso, o transformou em uma das ferramentas mais utilizadas para
gerenciar cronogramas de atividade de projeto e seus respectivos recursos. Dentre os benefcios do seu
uso,esto:
Melhorrepresentaodocronograma(Representaointuitiva)
Melhorrepresentaodasatividadesdoprojetoeseusrecursos
Melhorvisualizaodasdepndenciasentreasatividades
Boaformadeavaliaroscustosdetempoerecursos

Na Figura 2 podemos ver o cronograma resumido das atividades do projeto, nele mostrado
apenas as etapas mais superiores do projeto e os ciclos que vo ser executados. Tambm possivel
visualizar os recursos utilizados nas atividades, no nosso caso todos osenvolvidosparticipamdetodasas
etapaseciclosdefinidos.

21

Figura2.Cronogramaresumidodoprojeto(DiagramadeGantt)

Na Figura 3 e 4, temos o cronograma mais detalhado do projeto, onde as atividades mais

especificas de cada fase so exibidas, informadoseusdiaserecursosnecessrios,almdasdependncias
comoutrasatividades.

Figura3.Cronogramadetalhadodoprojeto(DiagramadeGantt)

22


Figura4.CronogramadetalhadodoprojetoContinuao(DiagramadeGantt)

Nas Figuras 5 e 6 vemos de fato o diagrama de Gantt gerado pelos dados das atividades,
recursos e tempo visualizados nas imagens anteriores. Com essas imagens conseguimos acompanhar de
formamaisintuitivaoandamentodoprojeto.

Figura5.DiagramadeGanttdoProjeto

23


Figura6.DiagramadeGanttdoProjetoContinuao

5.OrganizaodoPessoal

Para uma organizao desenvolver um projeto de software necessrio destinar uma equipe
especializada com ocontextodoprojeto.Estaatividadedeindicaoumatarefadogerentedeprojetos.
PRESSMAN (2006) sugere que a montagem da estrutura deumaequipedependedoestilodegestoda
organizao, da quantidade de pessoas que formaro a equipe e seus nveis de aptido e da dificuldade
geraldoproblema.
No caso do projeto Remoo Interna a equipe faz parte do setor de informtica da instituio
sendoconsideradooscritriosdoestilodegestodaorganizaoenveldeaptidodaequipe.

5.1Estruturadaequipe

Vrias atividades do projeto so conhecidas e executadas por todos os membros da equipe.

Neste projeto temos o Gestor do Projeto que o responsvel por planejar, executar, acompanhar as
atividades do projeto e garantir que o processo seja entendido e seguido por todos os envolvidos e os
analistas, responsveis pela modelagem e implementao dos requisitos do projeto. O projeto contar
comdoisanalistas.

24
5.2Mecanismosdecomunicao

Os mecanismos de comunicao da equipe so utilizados para garantir que asinformaessejam

disponibilizadas de forma adequada a todos os interessadosnomomentooportuno.Entreosmembrosda
equipe a comunicao pode ser formal ou informal. Os meios para comunicao formal so documentos
escritos e reunies estruturadas e para a informal uso de emails e encontros pessoais para troca de
ideias.

5.3UsodoEdublogcomoferramentadeapoio

O uso do Edublog mostrouse como uma importante ferramenta de apoio nas atividades de
elaborao doplanodeprojetodesoftware,jquetodososmembrospodemdivulgarsuasatividadesde
forma clara e acessvel, possibilitando que o conhecimento produzido seja compartilhado e difundido. A
caracterstica mais interessante verificada nessa ferramenta de apoio a disseminao do conhecimento
atravs de sua publicidade, ou seja, no h o porqu no compartilhar os saberes e sufocar o
conhecimento.

6PRECAUESTOMADASPARAASSEGURARECONTROLARAQUALIDADEDO
PRODUTODESW

Algumasaesforamdefinidasparagarantiraqualidadedoprodutodesoftware,soelas:

realizaodetestesdeunidade
realizaodetestesdeintegrao
realizaodetestesdeinterface
realizaodetestesdeconfigurao
realizaoperidicasderevisestcnicas.

25
7REFERNCIASBIBLIOGRFICAS

LORENZ.M,KIDDJ.,ObjectOrientedSoftwareMetrics,PrenticeHall,1994.
PRESSMAN,RogerS.Engenhariadesoftware.6ed.PortoAlegre:Bookman,2006.
GUIA PMBOK. Um guia do conjunto de conhecimentos em gerenciamento de projetos. 4 ed.
Pennsylvania:ProjectManagementInstitute,2008.

26