Plano de Projeto - Sistema Ômicron - Jeirlan e José Henrique

Universidade Federal de Sergipe
Departamento de Ciência da Computação

Mestrado em Ciência da Computação
Plano de Projeto
Alunos:
Jeirlan Correia Palmeira
José Henrique de Melo Cardoso
Professor:
Rogério P. C. Nascimento
Título do Projeto: Sistema Ômicron
Versão: 1.00
Plano de Projeto Página 1 de 20

Ultima Atualização: 15/11/yyyy 14:11:09
<logo>
Índice
1. INTRODUÇÃO ............................................................................................................... 3
1.1. ÂMBITO DO PROJETO........................................................................................................................... 3
1.2. FUNÇÕES PRINCIPAIS DO PRODUTO DE SOFTWARE ............................................................................ 3
1.3. REQUISITOS COMPORTAMENTAIS OU DE PERFORMANCE ................................................................... 4
1.4. GESTÃO E RESTRIÇÕES TÉCNICAS ..................................................................................................... 5
2. ESTIMATIVAS DO PROJETO ............................................................................................ 5
2.1. DADOS HISTÓRICOS UTILIZADOS PARA AS ESTIMATIVAS ..................................................................... 5
2.2. TÉCNICAS DE ESTIMATIVA E RESULTADOS .......................................................................................... 5
2.2.1. TÉCNICAS DE ESTIMATIVA ............................................................................................................... 5
2.3. RESULTADOS ....................................................................................................................................... 7
2.4. RECURSOS DO PROJETO ................................................................................................................... 11
2.4.1. Recursos humanos ......................................................................................................................... 11
2.4.2. Recursos de software ..................................................................................................................... 11
2.4.3. Recursos do ambiente de desenvolvimento ................................................................................... 11
3. ANÁLISE E GESTÃO DE RISCOS ..................................................................................... 11
3.1. RISCOS DO PROJETO ......................................................................................................................... 11
3.2. TABELA DE RISCOS ............................................................................................................................ 12
3.3. REDUÇÃO E GESTÃO DO RISCO ........................................................................................................ 12
3.4. ESTRATÉGIAS GERAIS PARA GESTÃO DE RISCOS .............................................................................. 14
4. PLANEJAMENTO TEMPORAL ......................................................................................... 14
4.1. CONJUNTO DE TAREFAS DO PROJETO .............................................................................................. 14
4.2. DIAGRAMA DE GANTT ........................................................................................................................ 15
5. PLANOS AUXILIARES ................................................................................................... 17
5.1. GERÊNCIA DE ESCOPO ...................................................................................................................... 17
5.2. GERÊNCIA DE QUALIDADE.................................................................................................................. 18
5.3. GERÊNCIA DE COMUNICAÇÃO ............................................................................................................ 19

<logo>
1. Introdução
1.1. Âmbito do Projeto

Atualmente muitas das informações necessárias ao andamento das Sessões Plenárias ainda
são disponibilizadas através de documentos, informativos e pautas impressas em papel. Consultas a
dados de processos em pauta, peças processuais como relatório e voto, bem como o controle e
acompanhamento do julgamento de cada processo são realizados manualmente pelos Membros e
seus assessores, prejudicando o célere andamento das sessões.
O sistema visa a disponibilizar e a controlar o acesso às principais informações necessárias

para o bom andamento das sessões, em formato digital, proporcionando, assim, agilidade no acesso
à informação, além de uma redução de gastos com material impresso. Desta forma, pode-se atingir
maior celeridade nos julgamentos do Tribunal do Pleno.
1.2. Funções principais do produto de software

O sistema irá auxiliar nas atividades dos Membros e seus Assessores durante as Sessões
Plenárias. Mais especificamente, o sistema pretende facilitar o acompanhamento das pautas das
Sessões Plenárias e o controle dos julgamentos, oferecendo, entre outras, opções de visualização
on-line de informações dos processos em pauta, de acesso aos respectivos relatórios, de
visualização do voto da relatoria (somente após sua leitura em sessão e liberação por parte do
relator), e de registro do andamento da votação durante o julgamento.
Os requisitos que estão no escopo do produto de software são os seguintes:
i. Visualizar Sessões e Pautas: Os usuários poderão visualizar o calendário das sessões

plenárias, bem como as respectivas pautas.
ii. Visualizar dados do Processo: O Sistema irá permitir a visualização dos dados de um
processo em pauta por qualquer usuário.
iii. Visualizar Relatório de Processos em Pauta: Os Membros poderão visualizar os relatórios

dos processos em pauta.
iv. Publicar Voto: O Relator de um processo poderá tornar disponível, para os demais
Membros, o conteúdo do seu voto após a sua leitura em plenário. O mesmo poderá
ocorrer com os votos de vista.
v. Alterar Situação de Membro: O sistema permitirá ao Secretário do Pleno registrar

ausência, impedimento ou suspeição de algum membro nos julgamentos da sessão.
vi. Alterar Situação do Processo na Pauta: O sistema permitirá ao Secretário do Pleno

registrar o pedido de vista ou a retirada de pauta de qualquer processo.
vii. Indicar Processo a ser Julgado: O Controlador de Pauta informará qual o próximo
processo a ser julgado.
<logo>
viii. Controlar Votação: O Secretário do Pleno poderá efetuar o controle dos votos emitidos
pelo Relator e demais Membros. Esse controle poderá ser passado para um dos
Assessores.
ix. Acompanhar Votação: Os Membros e Assessores poderão acompanhar o andamento da

votação visualizando o registro feito pelo Secretário do Pleno (Controlador de Votação).
x. Registrar Decisão Colegiada: O Secretário do Pleno, ou um Assessor, efetuará o registro

da decisão colegiada ao final do julgamento de cada processo na sessão.
xi. Registrar Anotações no Julgamento: O Secretário do Pleno e Assessores poderão

registrar anotações sobre o julgamento bem como visualizar as anotações feitas pelos
demais.
xii. Exibir Informações no Telão: A Audiência do Plenário visualizará informações dos

processos e dos julgamentos através do Telão.
xiii. Publicar Extrato de Votação: O Secretário do Pleno poderá publicar o extrato da votação
no telão ao final do julgamento.
xiv. Emitir Extrato de Ata: O Sistema permitirá a emissão do Extrato de Ata pela Direção-
Geral.
xv. Gerenciar Pré-Pauta: A Secretaria Judiciária montará a Pré-Pauta indicando os

processos aptos a julgamento (com o voto já pronto). As pautas serão criadas a partir da
Pré-Pauta.
xvi. Alterar Ordem de Pauta: O Presidente poderá alterar a ordem da pauta.
xvii. Indicar Processos com Preferência: O Secretário do Pleno poderá indicar quais os
processos da pauta que têm pedido de preferência.
xviii. Ordenar Pauta Automaticamente: O sistema fará a ordenação automática dos

processos da pauta pela ordem: classe prioritária, processos com pedido de vista e por
data de autuação (mais antigos).
xix. Incluir Processo em Mesa: O Secretário do Pleno poderá efetuar a inclusão na pauta de
Processo em Mesa.
1.3. Requisitos comportamentais ou de performance
Os requisitos comportamentais ou de performance são os seguintes:
i. O sistema deverá ter disponibilidade de 99% durante a ocorrência de sessões plenárias.

Soluções de contingência deverão ser previstas para casos de indisponibilidade do
sistema.
ii. O Sistema deverá atender a cerca de 20 usuários on-line e simultâneos com tempo de
resposta inferior a dois segundos (2s).

<logo>
iii. O sistema deverá evitar que pessoas não autorizadas tenham acesso ao conteúdo
privado dos Membros do Plenário. Será exigido o login para se ter acesso a recursos
sensíveis do sistema.
iv. O sistema deverá ser bastante intuitivo quanto ao uso de suas funções, requerendo
pouco ou nenhum treinamento para ser utilizado. Testes de usabilidade serão
necessários para se garantir tal requisito.
1.4. Gestão e Restrições Técnicas

i. O Portal deverá importar do SADP os dados dos processos e as pautas criadas pela
SJD.
ii. O Portal deverá ser construído utilizando-se tecnologias Java livres.
iii. O Portal deverá usar componentes visuais ricos (Rich Client) com recursos de Ajax e
Push para interfaces Web.
2. Estimativas do Projeto
2.1. Dados históricos utilizados para as estimativas

Não foram utilizados pela falta de ferramenta de apoio para sistematização destes dados.
2.2. Técnicas de estimativa e resultados

Nesta seção é mostrado como efetuar o cálculo para estimar a duração do projeto, com
uso de algumas técnicas. Serão apresentadas as técnicas Lorenz & Kidd, pontos por
casos de uso e a aplicação do COCOMO II no Rational Unified Process (RUP).
2.2.1. Técnicas de estimativa

Uso da técnica de Lorenz & kidd:
i. Definir o número de classes chave.
ii. Encontrar o número de classes de suporte. Para isso, temos que classificar o tipo
de Interface do Produto e desenvolver um Multiplicador para as Classes de Suporte.
iii. Multiplicar a quantidade de classes-chave pelo Multiplicador para obter uma
estimativa do número de classes de suporte.
iv. Após isso, calcula-se a quantidade total de Classes, somando o nº de Classes-
Chave com o nº de Classes de Suporte.
v. 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.
vi. Determinar a quantidade de esforço estimada.
vii. Cálculo do tempo previsto para a elaboração do projeto.
Pontos por casos de uso

<logo>
Pontos de Casos de Uso foi desenvolvido por Gustav Karner (1993) para medir o tamanho do
software através da quantidade, tamanho e complexidade dos casos de uso. A figura abaixo
representa o processo de contagem.
Figura 1 - Técnica de pontos por casos de uso

Vejamos como realizar o cálculo, passo a passo:
viii. Identificar a quantidade de atores, com os respectivos pesos, conforme
tabela abaixo:
Tipo de Descrição Peso

Ator
Simples Outro sistema que interage através de uma interface 1

programada da aplicação (API) definida.
Médio Outro sistema que interage através de um protocolo TCP/IP 2

ou de um ator humano que interage através de uma linha de
comando simples.
Complexo Ator humano que interage através de uma interface gráfica 3

Tabela 1 - Pesos de atores
ix. Calcular o peso dos casos com base na quantidade de transações que cada
caso de uso possui. Cada fluxo normal, alternativo ou de exceção é
contado como uma transação. A tabela abaixo ilustra como deve ser feita a
pontuação:
Tipo de Caso de Número de Transações (fluxos normais + Peso

Uso fluxos alternativos + fluxos de exceção)
Simples 1–3 5
Médio 4–7 10
Complexo Mais do que 7 15

Tabela 2 - Pesos de casos de uso
x. O total de pontos de casos de uso não ajustados (PCUN) é a soma dos
pesos não ajustados dos atores e dos casos de uso.
xi. Realizar o ajuste considerando os fatores técnicos, de acordo com a seguinte
fórmula: fator técnico = 0,6 + 0,01 * TFator, onde TFator representa a soma de
todos os fatores técnicos individuais. Nos resultados (seção 2.3), os fatores são
explicitados.
xii. Realizar o ajuste considerando os fatores ambientais de acordo com a
seguinte fórmula: fator ambiental = 1,4 - 0,03 * AFator, onde AFator representa a
soma de todos os fatores ambientais individuais. Nos resultados (seção 2.3), os
fatores são explicitados.
xiii. Calcular os pontos por casos de uso ajustados (PCU), considerando a
seguinte fórmula: PCU = PCUN * fator técnico * fator ambiental.
Com relação à produtividade, a literatura sugere uma produtividade entre 15 e 30 horas
para a implementação de um ponto de caso de uso, mas ela pode variar significativamente
entre equipes.

<logo>
COCOMO II no RUP
Distribuição máximas de esforços por fase do RUP
Elaboração: 37.5%
Construção: 62.5%
Transição: 12.5%
2.3. Resultados
Nesta seção, será dada a estimativa geral do projeto, baseando-se nos resultados da
aplicação das três técnicas explicadas na seção anterior: técnica de Lorenz & Kidd, técnica de
pontos por casos de uso e aplicação do COCOMO II no RUP.
Uso da Técnica de Lorenz & Kidd

i. Número de classes chave = 5
ii. Multiplicador GUI = 2.5
iii. 5 x 2.5 = 12.5 classes de suporte
iv. Número total de classes: 17.5
v. Em razão da inexperiência da equipe, consideraremos 20 dias-pessoa por classe: 17.5 x
20 => 350 dias.
Em uma situação hipotética ideal, considerando 3 pessoas envolvidas no projeto =>

116,66 dias, aproximadamente 5,9 meses
Uso da Técnica Pontos por Casos de Uso

i. Identificar a quantidade de atores, com os respectivos pesos:
Tipo de Ator Descrição Quantidade Peso Total
Simples Sistema API 0 1 0
Médio Sistema S/API 1 2 2
Complexo Ator humano 5 3 15
Total 17
Tabela 3 - Pesos de atores no sistema
ii. Calcular o peso dos casos.

iii. O total de pontos de casos de uso não ajustados (PCUN) é igual a 202, conforme
mostrado em seguida:
Distribuição dos Casos de Uso
Fluxos Peso do
Casos Fluxos Fluxos Total de % Caso Esforço % Por
de Caso de
de Uso Normais Alternativos Transações de Uso (d) Release
Exceção Uso
CSU 01 1 3 0 4 10 5% 20
8,11%
CSU 02 1 0 0 1 5 3% 10
CSU 03 1 1 2 4 10 5% 20
13,51%
CSU 04 1 1 0 2 5 3% 10
<logo>
CSU 05 1 0 1 2 5 3% 10
CSU 06 1 1 0 2 5 3% 10
CSU 07 1 1 0 2 5 3% 10
CSU 08 1 1 0 2 5 3% 10
CSU 09 1 0 0 1 5 3% 10
CSU 10 1 0 0 1 5 3% 10
21,62%
CSU 11 1 0 0 1 5 3% 10
CSU 12 1 0 0 1 5 3% 10
CSU 13 1 0 0 1 5 3% 10
CSU 14 1 1 0 2 5 3% 10
CSU 15 1 1 0 2 5 3% 10
CSU 16 1 1 0 2 5 3% 10
CSU 17 1 1 0 2 5 3% 10
16,22%
CSU 18 1 0 0 1 5 3% 10
CSU 19 1 0 0 1 5 3% 10
CSU 20 1 1 0 2 5 3% 10
CSU 21 1 1 0 2 5 3% 10
CSU 22 1 1 0 2 5 3% 10
CSU 23 1 2 0 3 5 3% 10
16,22%
CSU 24 1 0 0 1 5 3% 10
CSU 25 1 0 0 1 5 3% 10
CSU 26 1 2 1 1 5 3% 10
CSU 27 1 0 0 1 5 3% 10
CSU 28 1 0 0 1 5 3% 10
CSU 29 1 0 ´[] 1 5 3% 10 13,51%
CSU 30 1 0 0 1 5 3% 10
CSU 31 1 1 1 1 5 3% 10
CSU 32 1 1 1 1 5 3% 10
CSU 33 1 0 0 1 5 3% 10
10,81%
CSU 34 1 0 0 1 5 3% 10
CSU 35 1 0 0 0 5 3% 10
Total dos Pesos de Casos de Uso 185 100% 373 100,00%
Pontos dos Casos de Uso não Ajustados (Peso dos
202
Atores + Peso dos Casos de Uso)
Tabela 4 - Distribuição dos casos de uso
iv. Cálculo do fator técnico:

Fator Técnico
Fator Grau Peso Valor
T1 - Sistema distribuído 0 2 0
T2 - Requisitos de desempenho ou tempo de
4 1 4
resposta
T3 - Eficiência do usuário final 3 1 3
T4 - Complexidade do processamento interno 1 1 1
T5 – Reusabilidade 3 1 3
T6 – Instalabilidade 3 0,5 1,5
T7 – Usabilidade 4 0,5 2
T8 – Portabilidade 3 1 3
T9 – Modificabilidade 3 1 3
T10 – Concorrência 2 1 2
T11 - Inclui requisitos especiais de segurança 3 1 3
T12 - Provê acesso direto para terceiros 1 1 1

<logo>
T13 - Requer facilidades especiais para

1 1 1
treinamento dos usuários
Total do Fator Técnico 27,5
Fator Técnico (0,6 + 0,01 * Total do Fator Técnico) 0,875
Tabela 5 - Cálculo de fator técnico
v. Cálculo do fator ambiental:

Fator Ambiental
Fator Grau Peso Valor
Familiaridade com o modelo de ciclo de vida utilizado 3 1,5 4,5
Experiência com o domínio da aplicação 3 0,5 1,5
Experiência com as metodologias de desenvolvimento
3 1 3
utilizadas
Capacitação dos analistas 3 0,5 1,5
Motivação da equipe 5 1 5
Estabilidade dos requisitos 4 2 8
Membros da equipe atuando em tempo parcial 2 -1 -2
Dificuldade da linguagem de programação utilizada 3 -1 -3
Total do Fator Ambiental 18,5
Fator Ambiental (1.4 – 0,03 * Total do Fator Ambiental) 0,845
Tabela 6 - Cálculo de fator ambiental
vi. Calcular os pontos por casos de uso ajustados (PCU), considerando a seguinte fórmula:
PCU = PCUN * fator técnico * fator ambiental = 202 * 0,875 * 0,845 = 149
vii. Em razão da inexperiência da equipe, utilizou-se o fator de produtividade 20, que
representa que um ponto de caso de uso é implementado em 20h.
Esforço = 149,4 * 20h = 2987h = 373 dias.
Em uma situação hipotética ideal, considerando 3 pessoas envolvidas no projeto => 125
dias, aproximadamente 6,25 meses
COCOMO II no RUP
Distribuição de esforços máximos por fase do RUP
Elaboração: 37.5% => 44 dias
Construção: 62.5% => 74 dias
Transição: 12.5% => 15 dias
Distribuição das atividades durante as fases

Vamos considerar a estimativa apontada com uso da técnica Pontos por Casos de Uso, cujo esforço
total calculado foi de 373 dias.
A tabela abaixo mostra o resultado do cômputo:
Distribuição Distribuiçã
Distribuição Distribuiçã Distribuição
apontada o por
Fase efetivamente Release o por por release Atividade atividade
pelo realizada release (d)
COCOMO II (d)
Planejamento (3%) 0,9
Requisitos/Análise/Proj
Elaboração 37,50% 21,62% 1 8,11% 30 18,2
eto (60%)
Codificação (15%) 4,5
<logo>
Testes (22%) 6,7

30,2
2 13,51% 50 eto (60%)
Testes (22%) 11,1
32,3
3 21,62% 81 eto (40%)
Testes (37%) 29,8
24,2
4 16,22% 61 eto (40%)
Testes (37%) 22,4
Construção 62,50% 67,57%
24,2
5 16,22% 61 eto (40%)
Testes (37%) 22,4
20,2
6 13,51% 50 eto (40%)
Testes (37%) 18,6
4,0
Transição 12,50% 10,81% 7 10,81% 40 eto (10%)
Testes (47%) 19,0
TOTAL: 112,50% 100,00% - 100,00% 373 - 373
Tabela 7 - Distribuição de atividades e esforços
Através da tabela acima, percebe-se o seguinte:
1. O projeto será dividido em fases, seguinto o modelo de ciclo de vida adotado (o RUP).
2. A coluna distribuição apontada pelo COCOMO II representa uma proposta de distribuição de
atividades por fase do RUP. Na coluna distribuição efetivamente realizada, encontra-se a
distribuição proposta para esse projeto, que foi baseada na proposta do COCOMO II.
3. A coluna release apresenta o número da release que será entregue. Assim, temos que, para
cada fase do projeto (Elaboração, Construção e Transição), temos releases associadas
(releases de 1 a 7). Cabe destacar que os casos de usos tratados em cada release foram
destacados na seção 2.3, que realiza a aplicação da técnica de pontos por casos de uso.
4. As colunas distribuição por release e distribuição por release (d) mostram a estimativa de
duração para cada release (percentual e em dias), baseando-se na estimativa de pontos por
casos de uso previamente realizada.
5. As colunas atividade e distribuição por atividade mostram, para cada release, a distribuição
de esforço por atividade da engenharia de software. Os percentuais de distribuição de esforço
basearam-se na distribuição proposta por PRESSMAN, com alterações para considerar a
distribuição por fases do RUP. Assim, por exemplo, as atividades de codificação e testes na
fase de Elaboração possuem um percentual inferior ao proposto pelo PRESSMAN, focando
mais nas atividades de requisitos, análise e projeto. Na fase de construção, os testes e a
codificação são ainda mais enfatizados.

<logo>
2.4. Recursos do projeto
2.4.1. Recursos humanos

O projeto contará com 3 pessoas que exercerão os diversos papéis necessários à execução do
projeto para o desenvolvimento do software conforme quadro abaixo:
Papeis Exercido por

Gerente do projeto Jeirlan
Analista de Sistemas Jeirlan e Henrique
Projetista e Arquiteto Jeirlan e Henrique
Codificador Henrique
Testador Carla
Tabela 8 - Recursos humanos do projeto
2.4.2. Recursos de software

Não serão utilizados componentes de software, uma vez que não foram encontrados
componentes reutilizáveis que atendam aos requisitos especificados para o domínio.
2.4.3. Recursos do ambiente de desenvolvimento

Para o projeto será disponibilizado um ambiente com os seguintes recursos:
Hardware: Seis microcomputadores em rede local. Três servirão como estações de

trabalho sendo os demais utilizados como servidor de homologação, banco de
dados e aplicações.
Software: Como banco de dados será utilizado o Oracle 10g, como servidor Web o Jboss
4.0. Para persistência de dados objeto-relacional será utilizado o Hibernate. Para
apoiar o desenvolvimento nas diversas fases será utilizado o case IBM Rational
Rose. Como plataforma de desenvolvimento o Jboss Seam. O Office 2000 para
edição de documentos. Microsoft project 2007 para apoiar a gerência de projetos.
3. Análise e Gestão de Riscos
3.1. Riscos do projeto

Os riscos gerais, comuns a qualquer projeto são listados abaixo:
Nº Risco Projecto Técnico Negócio Comum Especial
1 Equipamento não disponível X
2 Requisitos incompletos X X
3 Uso de metodologias especiais X X
Problemas na busca da confiabilidae
4 requerida X X
5 Retenção de pessoas chaves X X
6 Sub-estimativas do esforço X X
Tabela 9 - Riscos gerais do projeto
Avaliação global dos riscos
1 – O gestor de software dá suporte ao projeto?
<logo>
Sim, seu papel é fundamental para o bom andamento e conclusão dentro do prazo,
do tempo e dos custos definidos.
2 – Os clientes estão entusiasmados com o projeto e o produto?
Os clientes estão muito entusiasmados, pois este projeto levará a construção de uma
excelente ferramenta que trará muitos benefícios para eles.
3 – Os engenheiros de software compreenderam bem os requisitos?
Todo um esforço foi feito para isto, pois erros nesta fase podem trazer sérios
problemas para o andamento do projeto.
4 – Os Clientes estiveram envolvidos na definição dos requisitos?
Sim, pois a participação destes é fundamental para validação e negociação dos
requisitos, bem como definição do escopo.
5 - O âmbito do projeto é estável?
Sim e já foi bem definido durante a fase de requisitos.
6 - Os engenheiros de software têm as competências requeridas?
Certamente, são profissionais especializados, treinados e experientes nas suas
áreas.
7 – Os requisitos do projeto são estáveis?
A maioria dos requisitos apresenta uma boa estabilidade uma vez que estão
amparados pelo regulamento interno do pleno. Mas, mesmo estes podem sofrer alterações a
qualquer momento caso decidam mudar o regulamento. Entretanto a metodologia de
desenvolvimento definida (RUP), prevê um desenvolvimento iterativo para amenizar a
questão da instabilidade dos requisitos.
8 – A equipe de desenvolvimento tem experiência na tecnologia a implementar ?
A equipe possui boa experiência na tecnologia. Entretanto será utilizada neste
projeto uma nova ferramenta CASE na qual todos são inexperientes.
9 - É adequado o número de pessoas da equipe de trabalho?
Sim, pois representa um projeto de pequeno para médio porte e os 3 integrantes
terão dedicação integral ao projeto. As próprias estimativas confirmam esta adequação, pois
indicam um período inferior a 7 meses.
3.2. Tabela de riscos

Os riscos do projeto foram identificados e classificados conforme tabela abaixo:
Nº Risco Categoria Probabilidade Impacto
Atendimento a requisitos de disponibilidade
1 e desempenho de forma insatisfatória Técnico 50,00% Catastrófico
2 Dificuldade de reunião com usuários Comum 50,00% Crítico
Ferramentas utilizadas não apresentarem o
3 comportamento esperado Técnico 30,00% Crítico
4 Tempo de resposta insatisfatório Técnico 50,00% Catastrófico
5 Desconhecimento do banco do SADP Técnico 50,00% Crítico
6 Dependência de sistemas externos Projeto 50,00% Marginal
Inexperiência da equipe na utilização da
7 ferramenta CASE adotada Projeto 60,00% Marginal
Tabela 10 - Riscos do projeto
3.3. Redução e Gestão do Risco

Para as atividades de redução, supervisão e gestão de riscos (RSGR), foram selecionados os
riscos de maior impacto e probabilidade significativa. São eles:

<logo>
1. Atendimento a requisitos de disponibilidade e desempenho de forma insatisfatória;

2. Tempo de resposta insatisfatório;
3. Dificuldades de reunião com usuários
1 - Atendimento a requisitos de disponibilidade e desempenho de forma

insatisfatória
Risco 01 Probabilidade: 50,00% Impacto: Catastrófico
Descrição: Este risco está ligado ao não atendimento de requisitos de desempenho

e disponibilidade especificados. O não atendimento destes requisitos implicará em
rejeição do sistema pelos usuários. Esta rejeição poderá trazer seria consequências
para equipe de desenvolvimento, pois são usuários de alto escalão.
Estratégia de redução: Antecipar para a primeira iteração da fase de elaboração

casos de uso que possibilitem teste destes requisitos não funcionais.
Plano de contingência: No caso de constatação do não atendimento ou na

impossibilidade dos testes antecipados, alocar recursos para contratação de
assessoria para avaliar tecnologia e recursos de hardware disponíveis e propor
solução.
Pessoa responsável: José Henrique (16/11/2010)
Status: Simulação agendada para o final da fase de elaboração.
2. Tempo de resposta insatisfatório
Risco 04 Probabilidade: 50,00% Impacto: Catastrófico
Descrição: Este risco também poderá levar a uma rejeição do sistema por parte dos
usuários, podendo, similarmente ao risco 01, repercutir negativamente para equipe.
Está ligado ao não atendimento de requisitos de tempo de resposta especificados.
Estratégia de redução: Antecipar para a primeira iteração da fase de elaboração

casos de uso que possibilitem teste deste requisito não funcional.
Plano de contingência: No caso de constatação do não atendimento ou na

impossibilidade dos testes antecipados, alocar recursos para contratação de
assessoria para avaliar tecnologia e recursos de hardware disponíveis e propor
solução.
Status : Simulação agendada para o final da fase de elaboração.
3. Dificuldades de reunião com usuários

<logo>
Risco 02 Probabilidade: 50,00% Impacto: Crítico
Descrição: Parte significativa dos usuários deste sistema ocupa cargo de gerência
ou são membros do alto escalão judiciário, não dispondo de tempo para atender
sempre que forem requisitados. Isto poderá dificultar o trabalho de levantamento e
desenvolvimento de requisitos e poderá causar sérios impactos nos prazos do
cronograma.
Estratégia de redução: Tentar agendar reunião o mais breve possível. Utilizar

alternativamente, serviço de email e telefone.
Plano de contingência: Alterar planejamento com realocação de casos de uso.

Negociar novos prazos.
Status: Simulação completada (16/11/2010).
3.4. Estratégias gerais para gestão de riscos

Para tanto, será necessário incluir na pauta de reuniões periódicas de andamento do projeto
o gerenciamento de riscos, visando: identificar novos riscos; facilitar e aumentar a exatidão do
entendimento dos riscos, especialmente ameaças; e, por conseguinte, reduzir as chances de falhas
decorrentes de eventos não planejados e/ou não identificados. Devem ser reuniões curtas semanais
entre representantes da equipe de desenvolvimento e o gerente de projetos.
Todos os riscos não previstos originalmente no plano de resposta a riscos devem ser
incorporados segundo um sistema de controle de mudança de riscos, similar ao mecanismo de
controle de mudança de escopo.
4. Planejamento Temporal
Nesta seção, serão definidas as datas de execução das tarefas e os responsáveis, com uso
do Diagrama de Gantt.
4.1. Conjunto de Tarefas do Projeto
O modelo de ciclo de vida usado foi o modelo iterativo, especificamente o RUP. Assim, as
atividades de planejamento, requisitos, análise, projeto, codificação e testes são executadas
continuamente durante todo o ciclo de vida de desenvolvimento do software.
A tabela seguinte ilustra como foi realizada a distribuição de esforços, e já foi explicada na
seção 2.3.
Distribuição Distribuiçã
Distribuição Distribuiçã Distribuição
apontada o por
Fase efetivamente Release o por por release Atividade atividade
pelo realizada release (d)
COCOMO II (d)
Elaboração 37,50% 21,62% 1 8,11% 30 Requisitos/Análise/Proj
18,2
eto (60%)
<logo>

Testes (22%) 6,7
30,2
2 13,51% 50 eto (60%)
Testes (22%) 11,1
32,3
3 21,62% 81 eto (40%)
Testes (37%) 29,8
24,2
4 16,22% 61 eto (40%)
Testes (37%) 22,4
Construção 62,50% 67,57%
24,2
5 16,22% 61 eto (40%)
Testes (37%) 22,4
20,2
6 13,51% 50 eto (40%)
Testes (37%) 18,6
4,0
Transição 12,50% 10,81% 7 10,81% 40 eto (10%)
Testes (47%) 19,0
TOTAL: 112,50% 100,00% - 100,00% 373 - 373
Tabela 11 - Distribuição de atividades e esforços
4.2. Diagrama de Gantt

O diagrama de Gantt é ilustrado em seguida. O gráfico encontra-se disponível em arquivo no MS
Project.

<logo>
Figura 2 - Gantt (Parte 1)
Figura 3 - Gantt (Parte 2)

Sobre o Gantt, são necessárias algumas observações importantes:
1. A duração total estimada para o projeto é de 204 dias, o que pode ser visto na linha 1.
a. De acordo com a estimativa realizada usando-se as técnicas mencionadas previamente,
chegou-se a uma estimativa de esforço de 373 dias.
b. Em teoria, deveríamos ter: 373 / 3 = 125 dias.
c. Tal diferença (204 dias, ao invés de 125 dias) ocorre pois as atividades não poderão ser
distribuídas entre os 3 membros da equipe do projeto. Por exemplo: a atividade de
codificação somente é realizada por Henrique, que é o único desenvolvedor do projeto; a
<logo>
atividade de testes somente é realizada por Carla, que é a única especialista em testes
do projeto; as atividades de Requisitos/Análise/Projeto são divididas entre os membros
Jeirlan e Henrique.
d. Outro motivo para a duração maior é que o segundo o modelo de ciclo de vida escolhido
não se recomenda a sobreposição de iterações. Assim, para se iniciar o desenvolvimento
da release 2, é necessário realizar a entrega da release 1.
2. Foram definidos 3 marcos, para delinear o final de cada fase do projeto.
3. O sistema aqui entitulado Ômicron foi, de fato, desenvolvido por uma organização em Aracaju/SE
no passado recente. A duração total estimada para o projeto está condizente com o realmente
ocorreu na prática. Isso reforça o poder do uso das técnicas de estimativa de esforço e duração
do projeto.
4. Em cada release serão realizados um conjunto de casos de uso que, no diagrama, estão
numerados de 1 a 35 para fins de sigilo das informações referentes ao sistema em questão. A
tabela 4 demonstra como foi feita a distribuição de casos de uso por release.
5. Planos auxiliares
5.1. Gerência de escopo

Cada mudança de escopo deverá passar por fases predefinidas até que seja considerada
concluída. Estas fases são:
• Solicitada: o solicitante submete um problema ou alteração, que ainda será avaliado;

• Avaliada: a solicitação é avaliada pelo “Avaliador”. Este será indicado pelo Gerente do
Projeto e será o responsável pela análise de impacto das solicitações recebidas;
• Aprovada: o avaliador julga viável o pedido de mudança no escopo do projeto. O gerente do
projeto autoriza a modificação;
• Rejeitada: o avaliador julgou inviável atender à solicitação;
• Modificação Implementada: as mudanças solicitadas para o projeto foram efetuadas pelo
“Modificador”;
• Cancelada: ocorre quando o Gerente do Projeto decide cancelar uma alteração para que o
projeto não seja prejudicado;
• Concluída: após a fase “Modificação Implementada” o “Verificador” checa se a alteração foi
realmente atendida de forma satisfatória, neste caso a alteração alcança sua fase final de
“Concluída”. Caso haja falha na verificação, a mudança volta à fase “Aprovada” para que seja
reimplementada pelo “Modificador”.
Assim como o Avaliador, o Modificador e o Verificador também serão designados pelo

Gerente do Projeto em tempo oportuno. O Gerente de Projeto deverá ser notificado de todas as
mudanças solicitadas para o projeto, como também dará a autorização necessária para a aceitação
da mudança. Todos os procedimentos acima descritos deverão ser cadastrados e monitorados no
Sistema de Gerência de Escopo, que serão disponibilizados para a equipe desenvolvedora.
Solicitação de alteração
Como pré-requisito para a aceitação, uma solicitação deverá conter os seguintes dados, que deverão
ser preenchidos pelo solicitante:

<logo>
• Descrição;
• Justificativas;
• Impacto se não implementada;
• Alternativas consideradas.
Avaliação de Impacto e renegociação
Ao proceder a avaliação de uma solicitação, o Avaliador deverá obter os itens do produto que
serão afetados pela alteração. O Gerente de Projeto irá efetuar o levantamento das alterações de
Custo, de Cronograma e de Recursos que resultarão da alteração solicitada. Em seguida negociará
as possíveis mudanças do Plano do Projeto com os stakeholders. Após o consentimento dos
interessados a mudança é autorizada.
5.2. Gerência de qualidade

Durante o projeto serão aplicadas várias atividades e técnicas para garantir a qualidade
dentro do gerenciamento do projeto.
Elas estão listadas a seguir:
1 – Teste de Unidade - É um método de testar unidades individuais do código fonte se

estão funcionando de maneira correta. A unidade é a menor parte testável de uma aplicação.
2 – Teste de Integração - É a fase do teste de software em que módulos são combinados

e testados em grupo.
3 – Teste de Sistema- É a fase do teste de software em que o sistema completo

(integrado) é testado num ambiente de produção.
4 – Validação do Protótipo - O Protótipo é um produto que ainda não foi comercializado,

mas está em fase de testes ou de planejamento. Usa-se a técnica de validação do protótipo para ter a
aprovação do patrocinador e de toda a equipe no decorrer das atividades de desenvolvimento.
No sistema de Assinatura de Revistas também serão utilizadas ferramentas para gerar

documentos que possam controlar e gerenciar a garantia da qualidade.
O documento que será utilizado em todo a implementação do sistema é o Plano de

Teste, que consiste numa modelagem detalhada do fluxo de trabalho. Plano de teste será
desenvolvido de acordo com cada caso de uso produzido, assim o plano conterá os diversos cenários
possíveis para a execução dos casos de uso.
Outro documento produzido é o documento de Homologação dos planos de teste, que

será de responsabilidade do analista de sistema, e ele é feito seguindo de molde o plano de teste,
que irá validar se o sistema está fazendo o que deve ser feito.

<logo>
5.3. Gerência de comunicação

Diante de um cenário favorável, com equipes trabalhando juntas, sem distanciamento
geográfico, um projeto com poucas e pequenas equipes, o gerenciamento de comunicação consegue
ser facilmente executado, com um nível não tão complexo de detalhamento.
A característica fundamental do plano de gerenciamento de comunicações é reportar o

andamento do projeto, identificando como, por quem, quando e de que forma foi feito.
Formas de relatar o andamento do projeto:
1 – Reunião Diária
Participantes Toda a Equipe do Projeto
Descrição Reunião de início do dia para definição das principais atividades programadas
para o dia e pendências do dia anterior.
Responsável Analista de Sistema
Duração 15 minutos – no início da manhã
Saída -
2 – Reunião Semanal
Descrição Reunião de início do dia para alinhamento das principais atividades

programadas para o dia.
Responsável Analista de Sistema e Gerente do Projeto
Duração 1 hora – final do ultimo dia da semana
Saída Ata simplificada, onde todos os participantes irão assinar suas atividades
desenvolvidas, Ata disponibilizada na intranet.
3 – Reunião Mensal
Participantes Toda a Equipe do Projeto + o Patrocinador
Descrição Serão apresentadas ao patrocinador as atas das reuniões semanais
Responsável Gerente do Projeto
Duração 1 hora – Ocorrer no primeiro dia útil do mês

<logo>
Saída Ata Simplificada com a aprovação das atividades desenvolvidas pelo

patrocinador
4 – Intranet
Descrição A distribuição das informações envolvendo a coleta e o compartilhamento das

informações às partes interessadas, durante todo o ciclo de vida do projeto.
Responsável Gerente do Projeto e Analista do Sistema
Duração -
Saída -
5 – E-mail
Descrição Qualquer anormalidade no andamento do projeto e também no final do dia,

será enviada um e-mail explicitando o andamento de suas atividades.
Responsável Analista de Sistema e Gerente do Projeto
Duração -
Saída -


Plano de Projeto - Sistema Ômicron - Jeirlan e José Henrique

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Plano de Projeto - Sistema Ômicron - Jeirlan e José Henrique

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade Federal de Sergipe

Departamento de Ciência da Computação

Título do Projeto: Sistema Ômicron

Plano de Projeto Página 1 de 20

Plano de Projeto Página 2 de 20

1.1. Âmbito do Projeto

O sistema visa a disponibilizar e a controlar o acesso às principais informações necessárias

1.2. Funções principais do produto de software

Os requisitos que estão no escopo do produto de software são os seguintes:

i. Visualizar Sessões e Pautas: Os usuários poderão visualizar o calendário das sessões

iii. Visualizar Relatório de Processos em Pauta: Os Membros poderão visualizar os relatórios

v. Alterar Situação de Membro: O sistema permitirá ao Secretário do Pleno registrar

vi. Alterar Situação do Processo na Pauta: O sistema permitirá ao Secretário do Pleno

ix. Acompanhar Votação: Os Membros e Assessores poderão acompanhar o andamento da

x. Registrar Decisão Colegiada: O Secretário do Pleno, ou um Assessor, efetuará o registro

xi. Registrar Anotações no Julgamento: O Secretário do Pleno e Assessores poderão

xii. Exibir Informações no Telão: A Audiência do Plenário visualizará informações dos

xv. Gerenciar Pré-Pauta: A Secretaria Judiciária montará a Pré-Pauta indicando os

xvi. Alterar Ordem de Pauta: O Presidente poderá alterar a ordem da pauta.

xviii. Ordenar Pauta Automaticamente: O sistema fará a ordenação automática dos

1.3. Requisitos comportamentais ou de performance

Os requisitos comportamentais ou de performance são os seguintes:

i. O sistema deverá ter disponibilidade de 99% durante a ocorrência de sessões plenárias.

Plano de Projeto Página 4 de 20

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

ii. O Portal deverá ser construído utilizando-se tecnologias Java livres.

2.1. Dados históricos utilizados para as estimativas

2.2. Técnicas de estimativa e resultados

2.2.1. Técnicas de estimativa

Plano de Projeto Página 5 de 20

Figura 1 - Técnica de pontos por casos de uso

Tipo de Descrição Peso

Simples Outro sistema que interage através de uma interface 1

Médio Outro sistema que interage através de um protocolo TCP/IP 2

Complexo Ator humano que interage através de uma interface gráfica 3

Tipo de Caso de Número de Transações (fluxos normais + Peso

Complexo Mais do que 7 15

Plano de Projeto Página 6 de 20

Uso da Técnica de Lorenz & Kidd

Em uma situação hipotética ideal, considerando 3 pessoas envolvidas no projeto =>

Uso da Técnica Pontos por Casos de Uso

Médio Sistema S/API 1 2 2

Complexo Ator humano 5 3 15

ii. Calcular o peso dos casos.

iv. Cálculo do fator técnico:

Plano de Projeto Página 8 de 20

T13 - Requer facilidades especiais para

v. Cálculo do fator ambiental:

Distribuição das atividades durante as fases

Testes (22%) 6,7

Plano de Projeto Página 10 de 20

2.4. Recursos do projeto

2.4.1. Recursos humanos

Papeis Exercido por

2.4.2. Recursos de software

2.4.3. Recursos do ambiente de desenvolvimento

Hardware: Seis microcomputadores em rede local. Três servirão como estações de

3. Análise e Gestão de Riscos

3.1. Riscos do projeto

3.2. Tabela de riscos

3.3. Redução e Gestão do Risco

Plano de Projeto Página 12 de 20

1. Atendimento a requisitos de disponibilidade e desempenho de forma insatisfatória;