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

8/8/2019 Plano De Projeto - Sistema Ômicron - Jeirlan e José Henrique

http://slidepdf.com/reader/full/plano-de-projeto-sistema-omicron-jeirlan-e-jose-henrique 1/20

Plano de Projeto Página 1 de 20

Ultima Atualização: 15/11/yyyy 14:11:09

Universidade Federal de Sergipe

Departamento de Ciência da ComputaçãoMestrado 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



<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óximoprocesso 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ãonecessá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 tipode Interface do Produto e desenvolver um Multiplicador para as Classes de Suporte.

iii. Multiplicar a quantidade de classes-chave pelo Multiplicador para obter umaestimativa 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 dosoftware através da quantidade, tamanho e complexidade dos casos de uso. A figura abaixorepresenta 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, conformetabela abaixo:

Tipo deAtor

Descrição Peso

Simples Outro sistema que interage através de uma interfaceprogramada da aplicação (API) definida.

1

Médio Outro sistema que interage através de um protocolo TCP/IPou de um ator humano que interage através de uma linha decomando simples.

2

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 cadacaso de uso possui. Cada fluxo normal, alternativo ou de exceção écontado como uma transação. A tabela abaixo ilustra como deve ser feita apontuação:

Tipo de Caso deUso

Número de Transações (fluxos normais +fluxos alternativos + fluxos de exceção)

Peso

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 dospesos não ajustados dos atores e dos casos de uso.

xi. Realizar o ajuste considerando os fatores técnicos, de acordo com a seguintefórmula: fator técnico = 0,6 + 0,01 * TFator, onde TFator representa a soma detodos os fatores técnicos individuais. Nos resultados (seção 2.3), os fatores sãoexplicitados.

xii. Realizar o ajuste considerando os fatores ambientais de acordo com aseguinte fórmula: fator ambiental = 1,4 - 0,03 * AFator, onde AFator representa asoma de todos os fatores ambientais individuais. Nos resultados (seção 2.3), osfatores são explicitados.

xiii. Calcular os pontos por casos de uso ajustados (PCU), considerando aseguinte 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 significativamenteentre 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 daaplicação das três técnicas explicadas na seção anterior: técnica de Lorenz & Kidd, técnica depontos 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 x20 => 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 Usoi. 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

Tabela3

- 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, conformemostrado em seguida:

Distribuição dos Casos de Uso

Casosde Uso

FluxosNormais

FluxosAlternativos

Fluxosde

Exceção

Total deTransações

Peso doCaso de

Uso

% Casode Uso

Esforço(d)

% PorRelease

CSU 01 1 3 0 4 10 5% 208,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% 10CSU 06 1 1 0 2 5 3% 10CSU 07 1 1 0 2 5 3% 10

21,62%

CSU 08 1 1 0 2 5 3% 10CSU 09 1 0 0 1 5 3% 10CSU 10 1 0 0 1 5 3% 10

CSU 11 1 0 0 1 5 3% 10CSU 12 1 0 0 1 5 3% 10CSU 13 1 0 0 1 5 3% 10CSU 14 1 1 0 2 5 3% 10CSU 15 1 1 0 2 5 3% 10

16,22%

CSU 16 1 1 0 2 5 3% 10CSU 17 1 1 0 2 5 3% 10CSU 18 1 0 0 1 5 3% 10CSU 19 1 0 0 1 5 3% 10CSU 20 1 1 0 2 5 3% 10CSU 21 1 1 0 2 5 3% 10

16,22%

CSU 22 1 1 0 2 5 3% 10

CSU 23 1 2 0 3 5 3% 10CSU 24 1 0 0 1 5 3% 10CSU 25 1 0 0 1 5 3% 10CSU 26 1 2 1 1 5 3% 10CSU 27 1 0 0 1 5 3% 10

13,51%CSU 28 1 0 0 1 5 3% 10CSU 29 1 0 ´[] 1 5 3% 10CSU 30 1 0 0 1 5 3% 10CSU 31 1 1 1 1 5 3% 10CSU 32 1 1 1 1 5 3% 10

10,81%CSU 33 1 0 0 1 5 3% 10CSU 34 1 0 0 1 5 3% 10CSU 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

Atores + Peso dos Casos de Uso)202

Tabela 4 - Distribuição dos casos de uso

iv. Cálculo do fator técnico:

Fator TécnicoFator Grau Peso Valor

T1 - Sistema distribuído 0 2 0

T2 - Requisitos de desempenho ou tempo deresposta

4 1 4

T3 - Eficiência do usuário final 3 1 3T4 - Complexidade do processamento interno 1 1 1

T5 – Reusabilidade 3 1 3T6 – Instalabilidade 3 0,5 1,5

T7 – Usabilidade 4 0,5 2T8 – Portabilidade 3 1 3

T9 – Modificabilidade 3 1 3T10 – 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 paratreinamento dos usuários

1 1 1

Total do Fator Técnico 27,5Fator 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 AmbientalFator 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,5Experiência com as metodologias de desenvolvimento

utilizadas 3 1 3

Capacitação dos analistas 3 0,5 1,5Motivação da equipe 5 1 5

Estabilidade dos requisitos 4 2 8Membros da equipe atuando em tempo parcial 2 -1 -2

Dificuldade da linguagem de programação utilizada 3 -1 -3Total 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, querepresenta 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 => 125dias, 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çototal calculado foi de 373 dias.

A tabela abaixo mostra o resultado do cômputo:

Fase

Distribuiçãoapontada

peloCOCOMO II

Distribuiçãoefetivamente

realizadaRelease

Distribuição por

release

Distribuiçãopor release

(d)Atividade

Distribuição por

atividade(d)

Elaboração 37,50% 21,62% 1 8,11% 30

Planejamento (3%) 0,9Requisitos/Análise/Proj

eto (60%) 18,2Codificação (15%) 4,5



<logo>



Testes (22%) 6,7

2 13,51% 50


eto (60%)30,2

Codificação (15%) 7,6Testes (22%) 11,1

Construção 62,50% 67,57%

3 21,62% 81

Planejamento (3%) 2,4Requisitos/Análise/Projeto (40%)

32,3


4 16,22% 61


eto (40%) 24,2


5 16,22% 61


eto (40%) 24,2Codificação (20%) 12,1

Testes (37%) 22,4

6 13,51% 50


eto (40%)20,2


Transição 12,50% 10,81% 7 10,81% 40


eto (10%) 4,0

Codificação (40%) 16,1

Testes (47%) 19,0TOTAL: 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 deatividades por fase do RUP. Na coluna distribuição efetivamente realizada , encontra-se adistribuiçã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, paracada 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 foramdestacados 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 deduração para cada release (percentual e em dias), baseando-se na estimativa de pontos porcasos de uso previamente realizada.

5. As colunas atividade e distribuição por atividade mostram, para cada release, a distribuiçãode esforço por atividade da engenharia de software. Os percentuais de distribuição de esforçobasearam-se na distribuição proposta por PRESSMAN, com alterações para considerar adistribuição por fases do RUP. Assim, por exemplo, as atividades de codificação e testes nafase de Elaboração possuem um percentual inferior ao proposto pelo PRESSMAN, focandomais nas atividades de requisitos, análise e projeto. Na fase de construção, os testes e acodificaçã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 doprojeto 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 encontradoscomponentes 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 detrabalho sendo os demais utilizados como servidor de homologação, banco dedados e aplicações.

Software: Como banco de dados será utilizado o Oracle 10g, como servidor Web o Jboss4.0. Para persistência de dados objeto-relacional será utilizado o Hibernate. Paraapoiar o desenvolvimento nas diversas fases será utilizado o case IBM RationalRose. Como plataforma de desenvolvimento o Jboss Seam. O Office 2000 paraediçã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 X2 Requisitos incompletos X X

3 Uso de metodologias especiais X X

4Problemas na busca da confiabilidaerequerida X X

5 Retenção de pessoas chaves X X6 Sub-estimativas do esforço X X

Tabela 9 - Riscos gerais do projeto

Avaliação global dos riscos1 – 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 umaexcelente 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 dosrequisitos, 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ãoamparados pelo regulamento interno do pleno. Mas, mesmo estes podem sofrer alterações aqualquer momento caso decidam mudar o regulamento. Entretanto a metodologia dedesenvolvimento definida (RUP), prevê um desenvolvimento iterativo para amenizar aquestã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 nesteprojeto 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, poisindicam 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

1Atendimento a requisitos de disponibilidadee desempenho de forma insatisfatória Técnico 50,00% Catastrófico

2 Dificuldade de reunião com usuários Comum 50,00% Crítico

3Ferramentas utilizadas não apresentarem ocomportamento esperado Técnico 30,00% Crítico

4 Tempo de resposta insatisfatório Técnico 50,00% Catastrófico5 Desconhecimento do banco do SADP Técnico 50,00% Crítico6 Dependência de sistemas externos Projeto 50,00% Marginal

7Inexperiência da equipe na utilização daferramenta 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 osriscos 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 formainsatisfatória

Risco 01 Probabilidade: 50,00% Impacto: Catastrófico

Descrição: Este risco está ligado ao não atendimento de requisitos de desempenhoe disponibilidade especificados. O não atendimento destes requisitos implicará emrejeição do sistema pelos usuários. Esta rejeição poderá trazer seria consequênciaspara 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 naimpossibilidade dos testes antecipados, alocar recursos para contratação deassessoria para avaliar tecnologia e recursos de hardware disponíveis e proporsolução.

Pessoa responsável: José Henrique (16/11/2010)

Status: Simulação agendada para o final da fase de elaboração.

empo 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 dosusuá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çãocasos de uso que possibilitem teste deste requisito não funcional.

Plano de contingência: No caso de constatação do não atendimento ou naimpossibilidade dos testes antecipados, alocar recursos para contratação deassessoria para avaliar tecnologia e recursos de hardware disponíveis e proporsolução.


Status : Simulação agendada para o final da fase de elaboração.

ificuldades 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ênciaou são membros do alto escalão judiciário, não dispondo de tempo para atendersempre que forem requisitados. Isto poderá dificultar o trabalho de levantamento e

desenvolvimento de requisitos e poderá causar sérios impactos nos prazos docronograma.

Estratégia de redução: Tentar agendar reunião o mais breve possível. Utilizaralternativamente, 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 decontrole 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 usodo Diagrama de Gantt.

4.1. Conjunto de Tarefas do ProjetoO 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 executadascontinuamente 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 naseção 2.3.

Fase

Distribuiçãoapontada

peloCOCOMO II

Distribuiçãoefetivamente

realizadaRelease

Distribuição por

release

Distribuiçãopor release

(d)Atividade

Distribuição por

atividade(d)

Elaboração 37,50% 21,62% 1 8,11% 30Planejamento (3%) 0,9

Requisitos/Análise/Projeto (60%) 18,2



<logo>




2 13,51% 50


eto (60%)30,2

Codificação (15%) 7,6

Testes (22%) 11,1

Construção 62,50% 67,57%

3 21,62% 81


eto (40%)32,3


4 16,22% 61


eto (40%) 24,2


5 16,22% 61

Planejamento (3%) 1,8

Requisitos/Análise/Projeto (40%)

24,2


6 13,51% 50


eto (40%)20,2


Transição 12,50% 10,81% 7 10,81% 40


eto (10%) 4,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 MSProject.



<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 serdistribuídas entre os 3 membros da equipe do projeto. Por exemplo: a atividade decodificaçã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 testesdo projeto; as atividades de Requisitos/Análise/Projeto são divididas entre os membrosJeirlan e Henrique .

d. Outro motivo para a duração maior é que o segundo o modelo de ciclo de vida escolhidonão se recomenda a sobreposição de iterações. Assim, para se iniciar o desenvolvimentoda 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 realmenteocorreu na prática. Isso reforça o poder do uso das técnicas de estimativa de esforço e duraçãodo projeto.

4. Em cada release serão realizados um conjunto de casos de uso que, no diagrama, estãonumerados de 1 a 35 para fins de sigilo das informações referentes ao sistema em questão. Atabela 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çãoAo 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 -

Documents

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