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. 1.2. 1.3. 1.4.
2.

ÂMBITO DO PROJETO........................................................................................................................... 3 FUNÇÕES PRINCIPAIS DO PRODUTO DE SOFTWARE ............................................................................ 3 REQUISITOS COMPORTAMENTAIS OU DE PERFORMANCE ................................................................... 4 GESTÃO E RESTRIÇÕES TÉCNICAS ..................................................................................................... 5

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. 3.2. 3.3. 3.4.
4.

RISCOS DO PROJETO ......................................................................................................................... 11 TABELA DE RISCOS ............................................................................................................................ 12 REDUÇÃO E GESTÃO DO RISCO ........................................................................................................ 12 ESTRATÉGIAS GERAIS PARA GESTÃO DE RISCOS .............................................................................. 14 CONJUNTO DE TAREFAS DO PROJETO .............................................................................................. 14 DIAGRAMA DE GANTT ........................................................................................................................ 15 GERÊNCIA DE ESCOPO ...................................................................................................................... 17 GERÊNCIA DE QUALIDADE.................................................................................................................. 18 GERÊNCIA DE COMUNICAÇÃO ............................................................................................................ 19

PLANEJAMENTO TEMPORAL ......................................................................................... 14

4.1. 4.2.
5.

PLANOS AUXILIARES ................................................................................................... 17

5.1. 5.2. 5.3.

Plano de Projeto

Página 2 de 20 Ultima Atualização: 15/11/yyyy 14:11:09

<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.
Plano de Projeto Página 3 de 20 Ultima Atualização: 15/11/yyyy 14:11:09

<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çãoGeral. 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).
Plano de Projeto Página 4 de 20 Ultima Atualização: 15/11/yyyy 14:11:09

<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 ClassesChave 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

Plano de Projeto

Página 5 de 20 Ultima Atualização: 15/11/yyyy 14:11:09

<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 Ator Simples Médio Descrição Outro sistema que interage através de uma interface programada da aplicação (API) definida. Outro sistema que interage através de um protocolo TCP/IP ou de um ator humano que interage através de uma linha de comando simples. Ator humano que interage através de uma interface gráfica 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 Uso Simples Médio Complexo Número de Transações (fluxos normais + fluxos alternativos + fluxos de exceção) 1–3 4–7 Mais do que 7 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.
Plano de Projeto Página 6 de 20 Ultima Atualização: 15/11/yyyy 14:11:09

Peso 1 2

Complexo

3

Peso 5 10 15

<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. ii. iii. iv. v. Número de classes chave = 5 Multiplicador GUI = 2.5 5 x 2.5 = 12.5 classes de suporte Número total de classes: 17.5 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 Sistema API Sistema S/API Ator humano 0 1 5 1 2 3 Total Tabela 3 - Pesos de atores no sistema ii. iii. Calcular o peso dos casos. O total de pontos de casos de uso não ajustados (PCUN) é igual a 202, conforme mostrado em seguida: % Caso Esforço % Por de Uso (d) Release 5% 3% 5% 3% 20 10 20 10 8,11% 13,51% Total 0 2 15 17

Simples Médio Complexo

Distribuição dos Casos de Uso Fluxos Peso do Casos Fluxos Fluxos Total de de Caso de de Uso Normais Alternativos Transações Exceção Uso CSU 01 1 3 0 4 10 CSU 02 1 0 0 1 5 CSU 03 1 1 2 4 10 CSU 04 1 1 0 2 5
Plano de Projeto

Página 7 de 20 Ultima Atualização: 15/11/yyyy 14:11:09

<logo> CSU 05 CSU 06 CSU 07 CSU 08 CSU 09 CSU 10 CSU 11 CSU 12 CSU 13 CSU 14 CSU 15 CSU 16 CSU 17 CSU 18 CSU 19 CSU 20 CSU 21 CSU 22 CSU 23 CSU 24 CSU 25 CSU 26 CSU 27 CSU 28 CSU 29 CSU 30 CSU 31 CSU 32 CSU 33 CSU 34 CSU 35 0 1 2 1 0 2 1 0 2 1 0 2 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 1 0 2 1 0 2 1 0 2 1 0 2 0 0 1 0 0 1 1 0 2 1 0 2 1 0 2 2 0 3 0 0 1 0 0 1 2 1 1 0 0 1 0 0 1 0 ´[] 1 0 0 1 1 1 1 1 1 1 0 0 1 0 0 1 0 0 0 Total dos Pesos de Casos de Uso Pontos dos Casos de Uso não Ajustados (Peso dos Atores + Peso dos Casos de Uso) 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 185 202 3% 3% 3% 3% 3% 3% 3% 3% 3% 3% 3% 3% 3% 3% 3% 3% 3% 3% 3% 3% 3% 3% 3% 3% 3% 3% 3% 3% 3% 3% 3% 100% 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 373

21,62%

16,22%

16,22%

13,51%

10,81% 100,00%

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

Plano de Projeto

Página 8 de 20 Ultima Atualização: 15/11/yyyy 14:11:09

<logo> T13 - Requer facilidades especiais para 1 treinamento dos usuários Total do Fator Técnico Fator Técnico (0,6 + 0,01 * Total do Fator Técnico) 1 1 27,5 0,875

Tabela 5 - Cálculo de fator técnico

v.

Cálculo do fator ambiental: Fator Ambiental Fator Grau 3 Peso 1,5 0,5 1 0,5 1 2 -1 -1 Valor 4,5 1,5 3 1,5 5 8 -2 -3 18,5 0,845

Familiaridade com o modelo de ciclo de vida utilizado

Experiência com o domínio da aplicação 3 Experiência com as metodologias de desenvolvimento 3 utilizadas Capacitação dos analistas 3 Motivação da equipe 5 Estabilidade dos requisitos 4 Membros da equipe atuando em tempo parcial 2 Dificuldade da linguagem de programação utilizada 3 Total do Fator Ambiental Fator Ambiental (1.4 – 0,03 * Total do Fator Ambiental) Tabela 6 - Cálculo de fator ambiental vi. vii.

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 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: Fase Distribuição apontada pelo COCOMO II 37,50%
Distribuição Distribuiçã efetivamente Release o por realizada release Distribuição por release (d)

Atividade Planejamento (3%) Requisitos/Análise/Proj eto (60%) Codificação (15%)

Distribuiçã o por atividade (d)

0,9 18,2 4,5

Elaboração

21,62%

1

8,11%

30

Plano de Projeto

Página 9 de 20 Ultima Atualização: 15/11/yyyy 14:11:09

<logo> Testes (22%) Planejamento (3%) Requisitos/Análise/Proj eto (60%) Codificação (15%) Testes (22%) Planejamento (3%) Requisitos/Análise/Proj eto (40%) Codificação (20%) Testes (37%) Planejamento (3%) Requisitos/Análise/Proj eto (40%) Codificação (20%) Testes (37%) Planejamento (3%) Requisitos/Análise/Proj eto (40%) Codificação (20%) Testes (37%) Planejamento (3%) Requisitos/Análise/Proj eto (40%) Codificação (20%) Testes (37%) Planejamento (3%) Requisitos/Análise/Proj eto (10%) Codificação (40%) Testes (47%) 6,7 1,5 30,2 7,6 11,1 2,4 32,3 16,1 29,8 1,8 24,2 12,1 22,4 1,8 24,2 12,1 22,4 1,5 20,2 10,1 18,6 1,2 4,0 16,1 19,0 373

2

13,51%

50

3

21,62%

81

4
Construção

16,22%

61

62,50%

67,57% 5 16,22% 61

6

13,51%

50

Transição

12,50%

10,81%

7

10,81%

40

TOTAL:

112,50%

100,00%

-

100,00%

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.

Plano de Projeto

Página 10 de 20 Ultima Atualização: 15/11/yyyy 14:11:09

<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 Gerente do projeto Analista de Sistemas Projetista e Arquiteto Codificador Testador

Exercido por Jeirlan Jeirlan e Henrique Jeirlan e Henrique Henrique 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 1 Equipamento não disponível 2 Requisitos incompletos 3 Uso de metodologias especiais Problemas na busca da confiabilidae 4 requerida 5 Retenção de pessoas chaves 6 Sub-estimativas do esforço X X Projecto X X X X X Técnico X Negócio Comum Especial X

X
X

Tabela 9 - Riscos gerais do projeto

Avaliação global dos riscos
1 – O gestor de software dá suporte ao projeto?
Plano de Projeto Página 11 de 20 Ultima Atualização: 15/11/yyyy 14:11:09

<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? áreas. Certamente, são profissionais especializados, treinados e experientes nas suas

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 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. será utilizada neste

3.2. Tabela de riscos
Os riscos do projeto foram identificados e classificados conforme tabela abaixo: Nº 1 2 3 4 5 6 7 Risco Atendimento a requisitos de disponibilidade e desempenho de forma insatisfatória Dificuldade de reunião com usuários Ferramentas utilizadas não apresentarem o comportamento esperado Tempo de resposta insatisfatório Desconhecimento do banco do SADP Dependência de sistemas externos Inexperiência da equipe na utilização da ferramenta CASE adotada Categoria Probabilidade Técnico Comum Técnico Técnico Técnico Projeto Projeto 50,00% 50,00% 30,00% 50,00% 50,00% 50,00% 60,00% Impacto Catastrófico Crítico Crítico Catastrófico Crítico Marginal 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:
Plano de Projeto Página 12 de 20 Ultima Atualização: 15/11/yyyy 14:11:09

<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. Pessoa responsável: José Henrique (16/11/2010) Status : Simulação agendada para o final da fase de elaboração.

3. Dificuldades de reunião com usuários
Plano de Projeto Página 13 de 20 Ultima Atualização: 15/11/yyyy 14:11:09

<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. Pessoa responsável: José Henrique (16/11/2010) 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. Fase Distribuição apontada pelo COCOMO II 37,50%
Distribuição Distribuiçã efetivamente Release o por realizada release Distribuição por release (d)

Atividade Planejamento (3%) Requisitos/Análise/Proj eto (60%)

Distribuiçã o por atividade (d)

0,9 18,2

Elaboração

21,62%

1

8,11%

30

Plano de Projeto

Página 14 de 20 Ultima Atualização: 15/11/yyyy 14:11:09

<logo> Codificação (15%) Testes (22%) Planejamento (3%) Requisitos/Análise/Proj eto (60%) Codificação (15%) Testes (22%) Planejamento (3%) Requisitos/Análise/Proj eto (40%) Codificação (20%) Testes (37%) Planejamento (3%) Requisitos/Análise/Proj eto (40%) Codificação (20%) Testes (37%) Planejamento (3%) Requisitos/Análise/Proj eto (40%) Codificação (20%) Testes (37%) Planejamento (3%) Requisitos/Análise/Proj eto (40%) Codificação (20%) Testes (37%) Planejamento (3%) Requisitos/Análise/Proj eto (10%) Codificação (40%) Testes (47%) 4,5 6,7 1,5 30,2 7,6 11,1 2,4 32,3 16,1 29,8 1,8 24,2 12,1 22,4 1,8 24,2 12,1 22,4 1,5 20,2 10,1 18,6 1,2 4,0 16,1 19,0 373

2

13,51%

50

3

21,62%

81

4
Construção

16,22%

61

62,50%

67,57% 5 16,22% 61

6

13,51%

50

Transição

12,50%

10,81%

7

10,81%

40

TOTAL:

112,50%

100,00%

-

100,00%

373

Tabela 11 - Distribuição de atividades e esforços

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

Plano de Projeto

Página 15 de 20 Ultima Atualização: 15/11/yyyy 14:11:09

<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
Página 16 de 20 Ultima Atualização: 15/11/yyyy 14:11:09

Plano de Projeto

<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:
Plano de Projeto Página 17 de 20 Ultima Atualização: 15/11/yyyy 14:11:09

<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.

Plano de Projeto

Página 18 de 20 Ultima Atualização: 15/11/yyyy 14:11:09

<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 Descrição Toda a Equipe do Projeto 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 Duração Saída Analista de Sistema 15 minutos – no início da manhã -

2 – Reunião Semanal
Participantes Descrição Toda a Equipe do Projeto Reunião de início do dia para alinhamento das principais atividades programadas para o dia. Responsável Duração Saída Analista de Sistema e Gerente do Projeto 1 hora – final do ultimo dia da semana Ata simplificada, onde todos os participantes irão assinar suas atividades desenvolvidas, Ata disponibilizada na intranet.

3 – Reunião Mensal
Participantes Descrição Responsável Duração Toda a Equipe do Projeto + o Patrocinador Serão apresentadas ao patrocinador as atas das reuniões semanais Gerente do Projeto 1 hora – Ocorrer no primeiro dia útil do mês

Plano de Projeto

Página 19 de 20 Ultima Atualização: 15/11/yyyy 14:11:09

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

– Intranet
Toda a Equipe do Projeto 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.

Participantes Descrição

Responsável Duração Saída

Gerente do Projeto e Analista do Sistema -

5 – E-mail
Participantes Descrição Toda a Equipe do Projeto 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 Duração Saída Analista de Sistema e Gerente do Projeto -

Plano de Projeto

Página 20 de 20 Ultima Atualização: 15/11/yyyy 14:11:09

Sign up to vote on this title
UsefulNot useful