Plano de projeto - Sistema de Remoção de Servidores

797 visualizações

Publicada em

Documento contendo o plano de projeto do sistema de remoção de servidores, utilizado como estudo de caso do módulo de gestão de projetos da matéria de engenharia de software do programa de pós-graduação em ciência da computação da UFS

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
797
No SlideShare
0
A partir de incorporações
0
Número de incorporações
175
Ações
Compartilhamentos
0
Downloads
13
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Plano de projeto - Sistema de Remoção de Servidores

  1. 1. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO Programa de Pós-Graduação em Ciência da Computação Engenharia de Software 2014.1 PLANO DE PROJETO DE SOFTWARE OO para produtos da Lacertae SW Diego Armando de Oliveira Meneses – 201411005115 Jislane Silva Santos Menezes – 201411006248 Thiago Couto de Almeida – 201411004833 São Cristóvão 2014 1
  2. 2. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO Programa de Pós-Graduação em Ciência da Computação Engenharia de Software 2014.1 PLANO DE PROJETO DE SOFTWARE OO para produtos da Lacertae SW Diego Armando de Oliveira Meneses – 201411005115 Jislane Silva Santos Menezes – 201411006248 Thiago Couto de Almeida – 201411004833 Trabalho realizado no módulo de Gestão de Projetos ministrado pelo Prof. Dr. Rogério Patrício Chagas do Nascimento na disciplina de Engenharia de Software da Pós-Graduação em Ciência da Computação da Universidade Federal de Sergipe (UFS). São Cristóvão 2014 2
  3. 3. SUMÁRIO 1 INTRODUÇÃO .................................................................................................................... 6 1.1 Âmbito do projeto ..................................................................................................... 6 1.2 Funções principais do produto d software ............................................................. 6 1.3 Requisitos comportamentais ou de performance .................................................. 8 1.4 Gestão e restrições técnicas...................................................................................... 8 2 ESTIMATIVA DO PROJETO............................................................................................ 9 2.1 Dados históricos utilizados para a estimativas....................................................... 9 2.2 Técnicas de estimativa e resultados......................................................................... 9 2.3 Resultados................................................................................................................ 10 2.4 Recurso do projeto.................................................................................................. 11 2.4.1 Recursos humanos ...................................................................................... 11 2.4.2 Recursos de software .................................................................................. 11 2.4.3 Recursos de hardware ............................................................................... 12 3 ANÁLISE E GESTÃO DE RISCOS ................................................................................. 13 3.1 Riscos do projeto...................................................................................................... 13 3.2 Tabela de riscos........................................................................................................ 14 3.3 Redução e gestão de riscos...................................................................................... 17 4 PLANEJAMENTO TEMPORAL..................................................................................... 22 4.1 Conjunto de tarefas do projeto ............................................................................. 22 4.2 Diagrama de Gantt ................................................................................................. 22 5 ORGANIZAÇÃO PESSOAL ............................................................................................ 26 5.1 Estrutura da equipe ................................................................................................ 26 5.2 Mecanismos de comunicação ................................................................................. 26 5.3 Uso do Edu-blog como ferramenta de apoio ........................................................ 26 6 PRECAUÇÕES TOMADAS PARAASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SW...................................................................................................... 27 7 REFERÊNCIAS ................................................................................................................. 28 SUMÁRIO DAS FIGURAS Figura 1: Diagrama de Caso de Uso ............................................................................................. 7 Figura 2: Cronograma Resumido do Projeto (Diagrama de Gantt) ......................................... 23 Figura 3: Cronograma Detalhado do Projeto (Diagrama de Gantt) ………………………..... 24 Figura 4: Diagrama de Gantt do Projeto………………………………………………………. 25 Figura 5: Diagrama de Gantt do Projeto - Continuação……………………………………… 25 3
  4. 4. 4
  5. 5. SUMÁRIO DAS TABELAS Tabela 1: Descrição do Problema ................................................................................................... 6 Tabela 2: Escopo Geral .................................................................................................................... 6 Tabela 3: Descrição Detalhada do Caso de Uso ............................................................................. 7 Tabela 4: Fatores Multiplicativos para Obter o Número de Classes de Suporte ..................... 10 Tabela 5: Riscos Gerais do Projeto .............................................................................................. 14 Tabela 6: Categorização dos Riscos do Projeto ........................................................................... 15 Tabela 7: Distribuição em dias das fases do projeto ................................................................... 22 5
  6. 6. 1 INTRODUÇÃO 1.1 Âmbito do Projeto O sistema de remoção de servidores é um software para gerenciamento de remoção interna de funcionários de uma determinada instituição pública X1 de ensino. O objetivo principal deste software é construir uma fila de espera por cargo, baseada em critérios definidos pela administração. Desta forma, cada servidor poderá manifestar sua intenção de ser removido para outra localidade (campus da instituição no estado), possibilitando que a administração possa realocar seus funcionários de maneira célere e transparente. A Tabela 1 descreve de forma sucinta o problema que o sistema propõe: o problema, os usuários afetados e o funcionamento ideal. A Tabela 2 exibe quais são as entradas, o processamento e saída que serão utilizadas pelo software. Problema - Gerenciar as remoções internas dos servidores entre os campus da instituição. - Falta de transparência e celeridade do processo de remoção. - Burocracia e complexidade para manifestar interesse em remoção. Usuários Afetados - Servidores Ativos (Docentes e técnicos administrativos). Funcionamento Ideal - Melhor gerenciamento das filas de espera. - Maior transparência e celeridade ao processo de remoção. - Simplificação do processo de pedido de remoção. Tabela - Descrição do Problema Entrada - Inserção de vagas. - Manifestação do pedido de interesse. Processamento - Ordenação da fila de espera com base nos critérios definidos. - Informar ao servidor (prioritário) a possibilidade de remoção. - Confirmação do interesse do servidor em ser removido. - Confirmação da administração do pedido da remoção. Saída - A remoção efetiva em um processo transparente e célere. Tabela - Escopo Geral 1.2 Funções Principais do Produto de Software Segundo LIMA (2013), as funcionalidades a serem executadas pelo sistema, a fim de atender aos requisitos do cliente, podem ser expressas através de casos de uso. Um caso de uso é 1 O termo “X” é empregado para manter o sigilo da instituição de ensino. 6
  7. 7. representado por uma elipse conectada a símbolos de atores, bonecos palito. Um ator representa o papel executado por uma entidade que envia ou recebe informações. Na Figura 1, o diagrama de caso de uso descreve de forma visual os principais usuários e funcionalidades do software. A Tabela 3 descreve de forma sucinta as funcionalidades expressas de forma gráfica nos casos de uso da Figura 1 e seus respectivos atores. Atores Funcionalidades Administração (Especialização do ator servidor) - Manter configurações do software (Inserção, Exclusão, Alteração e Consulta). - Manter edital de remoção (Inserção, Exclusão, Alteração e Consulta). - Manter vaga de remoção (Inserção, Exclusão, Alteração e Consulta). - Confirmação da remoção perante conformidade aos critérios estabelecidos. Servidor - Consultar fila de interesses cadastradas (fila de interesse ordenada de acordo com os critérios informados pela administração). - Manter interesse na remoção (Inserção, Exclusão, Alteração e Consulta). - Consultar vagas de remoção cadastradas. - Confirmar interesse de remoção solicitada. Tabela - Descrição detalhada do caso de uso 1.3 Requisitos Comportamentais ou de Performance A seguir serão listados os requisitos comportamentais ou de performance do Sistema de Remoção: • Reduzir a probabilidade de indisponibilidade do acesso ao sistema; • Minimizar a probabilidade de corrupção de dados; • Observação dos padrões e regras estabelecidas garantindo a transparência e corretude do processo; • Segurança de acesso, permitindo acesso somente aos servidores habilitados; • Facilidade para operar o produto; • Minimizar o esforço para realizar alterações, remover falhas e/ou adequar o produto a eventuais mudanças de ambiente. 1.4 Gestão e Restrições Técnicas A seguir serão listadas algumas restrições técnicas do Sistema de Remoção: • O sistema necessita ser desenvolvido utilizando arquitetura web. • O sistema necessita ser desenvolvido utilizando a linguagem JAVA utilizando o framework JSF. • O sistema deve utilizar o PostgreSQL como banco de dados. • O sistema deve utilizar o Subversion como controlador de versão. • O acesso ao sistema deve ser feito por um navegador web. 7 Figura - Diagrama de caso de uso
  8. 8. 8
  9. 9. 2 ESTIMATIVA DO PROJETO Segundo PRESSMAN(2006), o cálculo das estimativas é uma das atividades fundamentais do processo de gerenciamento de projetos de software. Nesta etapa é realizado o planejamento do esforço humano, o custo e da duração cronológica do projeto. Estimativas são baseadas em métricas históricas e empíricas. Os objetivos de utilização das métricas e estimativas são: ● Entender o comportamento e funcionamento do produto de software; ● Avaliar os padrões, metas e critérios de aceitação; ● Controlar processos produtos e serviços; ● Prever valores de atributos O uso correto das métricas e estimativas traz alguns benefícios, como: ● Indicar qualidade do produto; ● Formar base de dados para outros projetos; ● Avaliar produtividade; ● Ajudar na tomada de decisões estratégicas. 2.1 Dados Históricos Utilizados para as Estimativas A instituição X que executará o projeto não possui um histórico de elaboração de produtos de software. Não sendo possível estabelecer comparações e estimativas baseadas em um histórico. 2.2 Técnicas de Estimativa e Resultado Nesta subseção demonstra-se como foi efetuado o cálculo para estimar a duração do projeto (em dias). Para aferir esse esforço utilizou-se a métrica de Lorenz & Kidd (1994). A métrica de Lorenz & Kidd é composta dos passos descritos a seguir: 1. Definir o número de classes chave. 2. Encontrar o número de classes de suporte - é necessário classificar o tipo da interface do produto e desenvolver um multiplicador para as classes de suporte (a Tabela 4 apresenta uma lista de multiplicadores de acordo com o tipo de interface da aplicação a ser estimada). 3. Multiplicar a quantidade de classes chave pelo multiplicador obtendo uma estimativa do número de classes de suporte. 4. Calcular a quantidade total de classes, somando o número de classes chave com o número de classes de suporte. 9
  10. 10. 5. Multiplicar a quantidade total de classes (obtidas no item anterior) pelo número médio de unidades de trabalho (dias - pessoa) por classe. A métrica sugere entre 15 e 20 dias. 6. Determinar a quantidade de esforço estimada. 7. Calcular o tempo previsto para a elaboração do projeto. Interface Multiplicador Não gráfica 2 Baseada em textos 2,25 GUI 2,5 GUI complexa 3 Tabela - Fatores multiplicativos para obter o número de classes de suporte 2.3 Resultados Utilizando a métrica de Lorenz e Kidd (1994) descrita na sub-seção anterior, obtém-se os seguintes valores: 1. Número de Classes Principais: 4 classes: Servidor, Vaga, Interesse e Configurações. 2. Definição do multiplicador: Como a interface fora classificada como GUI, temos como 2,5 fator multiplicador (ver Tabela 4). 3. Número de classes de suporte: Nº Classes chave X multiplicador = 4 X 2.5 = 10 classes de suporte. 4. Número total de classes: Nº Classes Chave + Nº Classes de Suporte = 4 + 10 = 14 classes. 5. Definição do número médio de unidades de trabalho: Definiu-se que a unidade de trabalho será de 20 dias-pessoa já que não há um histórico para realização de estimativas. 6. Determinação da quantidade de esforço estimada. Nº Total de Classes X Unidades de trabalho = 14 X 20 = 280 dias. 7. Cálculo do tempo previsto para a elaboração do projeto. Primeiro obtemos a quantidade de dias corridos através do seguinte cálculo: 10
  11. 11. Dias corridos = Dias estimados X (dias por mês / dias úteis por mês). Dessa forma, temos: Dias corridos = 280 X (30/22) = 8400/22 = 381,81 = 382. Como teremos 3 pessoas envolvidas em todas as fases do projeto podemos dividir o número total de dias pela quantidade de pessoas envolvidas. Dias = 382 / 3 = 127,33 = 128 dias Tomando por base que o projeto será construído utilizando a metodologia de desenvolvimento iterativo e incremental e que o projeto será executado em dois ciclos, definiu-se que para o primeiro ciclo serão necessários 78 dias e no segundo ciclo será produzido em 50 dias. O primeiro ciclo é mais extenso que o outro, já que as tarefas mais importantes do sistema se encontram nesta fase. . 2.4 Recursos de Projeto Os recursos de projeto são elementos importantes para o planejamento e execução. O projeto de software utiliza recursos materiais (equipamentos e programas) e recursos humanos. O gerenciamento desses recursos promove uma utilização mais efetiva durante o andamento do projeto. 2.4.1 Gestão de Pessoas A gestão de pessoas envolve processos como identificação, atribuição de funções, responsabilidades, desenvolvimento e gerenciamento da equipe do projeto (DINSMORE; CAVALIERI,2008). No projeto Remoção, a equipe é composta por três membros que estão envolvidos em todas as fases do projeto. As funções executadas pelos membros serão detalhadas na subseção 5.1. A equipe é composta por três membros que estão envolvidos em todas as fases do projeto. As funções executadas pelos membros serão detalhadas na subseção 5.1. 2.4.2 Recursos de Software Os recursos de software utilizados no projeto são ferramentas de conhecimento público, amplamente utilizadas na comunidade, nenhum deles requer uma licença específica para sua utilização. São eles: ● Subversion (controlador de versão) 11
  12. 12. ● TortoiseSVN-1.8.5.25224-x64-svn-1.8.8 (cliente do Subversion) ● Apache/Tomcat 7.x (servidor de aplicação) ● Star UML 5.0 (ferramenta para elaboração de diagramas UML) ● DBDesigner 4 (ferramenta para elaboração DER) ● jdk-7u51-windows-x64 (máquina virtual JAVA) ● netbeans-7.4-javaee-windows (IDE de desenvolvimento) ● primefaces-4.0 (biblioteca de componentes do JSF) ● primefaces-4.0-sources (sources do Prime Faces) ● PostgreSQL 8.4 (Banco de dados) ● pgAdmin (cliente do PostgreSQL) ● postgresql-9.1.11-2-windows-x64 (driver para acesso ao banco de dados) ● OpenProj - 1.4 (ferramenta para elaboração do gráfico de Gantt) 2.4.3 Recursos de Hardware Os recursos de hardware exigidos pela aplicação são amplamente atendidos pela instituição. ● Computadores pessoais para cada membro da equipe em rede local; ● Servidor de desenvolvimento virtualizado; ● Servidor de treinamento virtualizado; ● Servidor de produção virtualizado. 12
  13. 13. 3 ANÁLISE E GESTÃO DE RISCOS Os riscos são problemas em potencial que podem ou não, vir a se concretizar. Em PRESSMAN (2006) encontramos três fundamentos conceituais que definem o risco: o futuro, as modificações e que métodos e ferramentas devem ser utilizados. O futuro é imprevisível, assim é difícil prever que riscos podem causar o insucesso do projeto de software. As modificações nos requisitos, ou em outros aspectos relacionados ao projeto como tecnologia de desenvolvimento e suporte podem resultar em atrasos de cronograma e por conseguinte o insucesso do projeto. Quanto aos métodos e ferramentas, que procedimentos de qualidade devem ser aplicados durante o projeto. A fim de minimizar os riscos, é necessário gerenciá-los. Segundo o PMBOK(2008), o gerenciamento de riscos do projeto inclui os processos relacionados com o planejamento, identificação, análise, elaboração de respostas, monitoramento e controle dos riscos em um projeto. Esta fase é conhecida por análise e gestão de risco que são ações que auxiliam uma equipe de software a compreender e gerenciar as incertezas do negócio. Alguns passos devem ser realizados para gerenciar esses riscos, são eles: ● Identificar os riscos ● Avaliar probabilidade de ocorrência ● Estimar o impacto ● Estabelecer o plano de contingência Os três primeiros passos resultam na tabela dos riscos do projeto, abordados na seção 3.2. O plano de contingência será abordado na seção 3.3. Os envolvidos nesta etapa são todos aqueles que fazem parte da gestão de qualidade do produto (Gerentes, Engenheiros de Software, Stakeholders). É importante a utilização da gestão de riscos, pois alguns riscos, se concretizados podem vir a suspender o processo de produção do produto (PRESSMAN,2006). 3.1 Riscos do Projeto Alguns riscos estão sempre presentes em quaisquer projeto de software, eles podem ser considerados riscos gerais e são listados na Tabela 5. Risco Projeto Técnico Negócio Comum Especial 13
  14. 14. Equipamento não disponível X Requisitos incompletos X X Uso de metodologias especiais X X Problemas na busca da confiabilidade requerida X X Retenção de pessoas chaves X X Subestimativas de esforço X X Tabela - Riscos gerais do projeto Avaliação Global do Risco: 1. O Gestor de Software dá suporte ao projeto? Sim. O gestor estará responsável por garantir o alcance do sucesso do produto de software, participando e informando aos interessados sobre o andamento do projeto. 2. Os Clientes estão entusiasmados com o produto? Sim. Pois a implantação do produto trará transparência e publicidade ao processo de seleção dos concursos de remoção interna. 3. Os Engenheiros de Software compreenderam bem os requisitos? Sim. Os engenheiros tem acesso aos requisitos legais (critérios definidos pela gestão do órgão) que determinam os parâmetros que influenciam na seleção. 4. Os Clientes estiveram envolvidos na definição dos requisitos? Sim. Os clientes expuseram de maneira formal quais os principais requisitos necessários para construir a aplicação. 5. O âmbito do projeto é estável? Não. O escopo do projeto é variável já que os requisitos legais podem ser alterados. 6. Os engenheiros de Software têm as competências requeridas? Sim. Os gerentes são qualificados para as atividades que lhes são propostas. 7. Os requisitos do projeto são estáveis? 14
  15. 15. Não. Como o instituto tem autoridade para reger os critérios de seleção para remoção interna, a influência da gestão é quem garante a estabilidade. 8. A Equipe de Desenvolvimento tem experiência na tecnologia que será utilizada? Sim. A equipe de desenvolvimento possui experiência acadêmica nas tecnologias que estão sendo utilizadas. 9. É adequado o número de pessoas da equipe de trabalho? Não é possível prever este quesito já que não há um histórico de desenvolvimento de projetos pela equipe. 3.2 Tabela de Riscos A tabela de riscos contém os riscos identificados no projeto, dispostos em ordem decrescente de probabilidade e impacto (PRESSMAN,2006). A Tabela 6 identifica para cada risco a sua categoria, probabilidade de ocorrência e impacto sobre o projeto em caso de concretização do risco. Foram identificados 20 riscos em diferentes categorias. Nº Risco Categoria Probabilidade Impacto 1 Iminência de greve Pessoal 85% Crítico 2 Influência de restrições governamentais associada à legislação que define o negócio Negócio 80% Catastrófico 3 Requisitos instáveis do projeto Negócio 80% Catastrófico 4 Uso de novas tecnologias Tecnologia 80% Crítico 5 Escopo instável do projeto Tamanho 75% Catastrófico 6 Alta visibilidade (expectativa) do número de clientes que usarão o produto Negócio 75% Crítico 7 Não utilização de revisões técnicas formais Processo 75% Crítico 15
  16. 16. 8 Descomprometimento da alta administração com o desenvolvimento do projeto Negócio 60% Crítico 9 Prazos e tempo para tarefas mal estimados - risco de projeto Negócio 60% Crítico 10 Restrições de interoperabilidade com o sistema de RH Negócio 50% Catastrófico 11 Falta de experiência da equipe na tecnologia Pessoal 50% Marginal 12 Mau uso das ferramentas de auxílio a construção do software Ambiente 35% Marginal 13 Imprevistos de pessoal Pessoal 30% Crítico 14 Uso incorreto de ferramentas CASE para análise, design e teste Processo 20% Crítico 15 Número de usuário do produto (crescimento do número de usuários) Tamanho 20% Marginal 16 Porcentagem de crescimento da base de dados Tamanho 20% Marginal 17 Impactos no orçamento da empresa Instituição Pública Negócio 15% Crítico 18 Volatilidade do pessoal da equipe Pessoal 15% Crítico 19 Colaboradores do projeto são também clientes do produto Pessoal 15% Marginal 20 Descontinuação de ferramentas de auxílio a construção de software Ambiente 10% Desprezível 16
  17. 17. Tabela - Tabela de Riscos e Categorização dos Riscos do Projeto 3.3 Redução e gestão de riscos O Plano de Redução, supervisão e gestão do risco (RSGR) é desenvolvido para ser utilizado quando um risco de fato se concretiza, ou seja, quando os planos de prevenção ao risco falharam ou quando os riscos tem probabilidade eminente de acontecer. Para identificar quais os riscos que terão o plano de contingência (RSGR) estabelecido, utilizou-se a métrica Categoria/Probabilidade, onde o ponto de corte é: riscos com categoria (Catastrófico e Crítico) igual ou acima de 50% de probabilidade de ocorrência (Os riscos que se aplicam a essa métrica foram destacados em vermelho na tabela de riscos). Greve Risco 1 Probabilidade: 85% Impacto: Crítico Descrição: Iminência de greve dos servidores ativos da instituição pública (Docentes e/ou técnicos administrativos) durante todo ou parte do período estabelecido para o projeto. Obs: esse risco foi classificado com uma alta probabilidade porque na instituição de ensino que usamos como escopo há uma indicação muito forte de greve, onde essa indicação será aprovada ou não no dia 29/04. http://www.sinasefe.org.br/v3/index.php/noticias-da-greve/991-greve-do-sinasefe-comeca-hoje Estratégia de redução: Não existe estratégia de redução. As greves em instituições públicas onde seus servidores ativos trabalham sobre um regime estatutário estão fora do escopo da gerência de projetos, ou seja, o gerente de projetos não tem competência sobre essa decisão. Plano de contingência: Alterar o cronograma e renegociar o prazo de entrega do produto. Contratar equipe terceirizada que não faça parte dos servidores ativos. Pessoa responsável: Thiago Couto de Almeida (criação 16/04/2014) Status: Situação completada (22/04/2014) Influência de restrições governamentais associada à legislação que define o negócio Risco 2 Probabilidade: 80% Impacto: Catastrófico Descrição: Critérios que norteiam a remoção dos servidores podem ser criados e alterados através de normativas do Ministério do Planejamento, Orçamento e Gestão (MPOG), tirando a autonomia do instituto em estabelecer critérios próprios para ordenar a fila de interesses. Estratégia de redução: Avaliação da legislação no que se refere a remoção de servidores na 17
  18. 18. administração pública. Plano de contingência: Reavaliar requisitos funcionais do projeto. Negociar novos prazos. Pessoa responsável: Thiago Couto de Almeida (criação 08/04/2014) Status: Situação completada (14/04/2014) Requisitos instáveis do projeto Risco 3 Probabilidade: 80% Impacto: Catastrófico Descrição: Requisitos do projeto instável. As mudanças de requisitos durante o desenvolvimento do projeto podem impactar significativamente o andamento do mesmo, podendo levar até a suspenção do projeto. Estratégia de redução: Proporcionar reuniões periódicas de conscientização dos benefícios da implantação do produto de software. Plano de contingência: Realizar a redefinição do escopo, alterar o cronograma e renegociar o prazo de entrega do produto. Pessoa responsável: Thiago Couto de Almeida (criação 15/04/2014) Status: Situação completada (18/04/2014) Uso de novas tecnologias Risco 4 Probabilidade: 80% Impacto: Crítico Descrição: A equipe do projeto não possui experiência nas tecnologias usadas para análise, projeto e desenvolvimento do produto de software, essa falta de conhecimento pode acarretar em atrasos no cronograma, isso acontece por causa do tempo estendido para se realizar as tarefas nas novas ferramentas (Curva de aprendizado muito grande). Estratégia de redução: Treinar a equipe de desenvolvimento nas novas tecnologias antes de iniciar o projeto. Plano de contingência: Alterar o cronograma e renegociar o prazo de entrega do produto. Pessoa responsável: Thiago Couto de Almeida (criação 16/04/2014) Status: Situação completada (22/04/2014) Escopo instável do projeto 18
  19. 19. Risco 5 Probabilidade: 80% Impacto: Catastrófico Descrição: Escopo do projeto instável Estratégia de redução: A instabilidade do escopo depende da alteração dos critérios de remoção, assim estas configurações devem ser parametrizadas de forma que o produto seja pouco modificado. Na ocorrência de alteração do escopo a estratégia é dividir as entregas do projeto. Plano de contingência: Realizar a revisão do escopo e entregar módulos parciais do produto; atualizar cronograma. Pessoa responsável: Thiago Couto de Almeida (criação 15/04/2014) Status: Situação completada (18/04/2014) Alta visibilidade (expectativa) do número de clientes que usarão o produto Risco 6 Probabilidade: 75% Impacto: Crítico Descrição: Este software terá como usuários uma grande parte dos servidores da instituição que aguardam durante anos a oportunidade de concorrerem em um edital de remoção. Estratégia: Cumprir as metas estabelecidas no plano de projeto de software para que os prazos sejam obedecidos. Plano de contingência: Reestabelecer novos prazos, e esclarecer aos usuários o porquê não foi possível entregar o software no prazos determinado. Pessoa responsável: Thiago Couto de Almeida (criação 08/04/2014) Status: Situação completada (14/04/2014) Não utilização de revisões técnicas formais Risco 7 Probabilidade: 75% Impacto: Crítico Descrição: A não utilização de revisões técnicas formais torna o software final sem qualidade, pois com a ausência dessa técnica não se consegue: descobrir erros de funções ou lógica, avaliar se o software esta em conformidade com os requisitos, garantir o uso dos padrões pré-definidos, uniformidade do software, apontar melhorias necessárias. A não utilização de revisões formais é causada pela falta de experiência da equipe em projetos de software gerenciados. Estratégia: Fazer um plano para utilização de revisões técnicas consolidadas no projeto. Plano de contingência: Revisar o projeto identificando as áreas afetadas e corrigindo os problemas com o uso adequado das revisões técnicas. 19
  20. 20. Pessoa responsável: Thiago Couto de Almeida (criação 16/04/2014) Status: Situação completada (2204/2014) Descomprometimento da alta administração com o desenvolvimento do projeto Risco 8 Probabilidade: 60% Impacto: Crítico Descrição: Descomprometimento da alta administração com o desenvolvimento do projeto Estratégia de redução: Integrar os stakeholders nas etapas de desenvolvimento do projeto Plano de contingência: Proporcionar reuniões periódicas de conscientização dos benefícios da implantação do produto de software; Gerenciar as expectativas dos interessados no projeto Pessoa responsável: Thiago Couto de Almeida (criação 15/04/2014) Status: Situação completada (18/04/2014) Prazos e tempo para tarefas mal estimados Risco 9 Probabilidade: 60% Impacto: Crítico Descrição: Prazos e tempo para tarefas mal estimados Estratégia de redução: Utilizar técnica do valor agregado para avaliar a condução do projeto. Realizar reuniões periódicas de acompanhamento de status do projeto Plano de contingência: Revisar escopo, atualizar cronograma e redistribuir as tarefas para a equipe sempre que necessário Pessoa responsável: Thiago Couto de Almeida (criação 15/04/2014) Status: Situação completada (18/04/2014) Restrições de interoperabilidade com o sistema de RH Risco 10 Probabilidade: 50% Impacto: Catastrófico Descrição: Os dados dos servidores são consultados no sistema de RH, se não existir a interoperabilidade a principal fonte de dados não será acessível. Estratégia: Notificar a empresa contratada responsável pelo sistema de RH, que qualquer 20
  21. 21. alteração que for ser realizada deverá ser informada com antecedência mínima de 15 dias e que a mesma entregue a documentação da alteração realizada. Plano de contingência: Alocar os esforços da equipe para reconstruir a integração entre os softwares. Pessoa responsável: Thiago Couto de Almeida (criação 08/04/2014) Status: Situação completada (15/04/2014) 21
  22. 22. 4. PLANEJAMENTO TEMPORAL Etapa responsável pelo planejamento temporal das atividades definindo as datas de execução das tarefas e os papéis responsáveis pela execução. 4.1 Conjunto de Tarefas do Projeto A metodologia utilizada para planejar o projeto é uma implementação do modelo interativo incremental em conjunto com as fases de processo definidas pela Lacertae SW, acrescentando a este modelo a fase de implantação e treinamento. Devido ao escopo do projeto e as necessidades de entrega de releases (versão funcional do software), o projeto foi dividido em 2 ciclos. O primeiro ciclo, por conter mais atividades importantes demanda um tempo maior. O tempo estimado para o processo de desenvolvimento do software foi de 382 dias corridos. A equipe destinada para o projeto possui 3 pessoas. Diante desta configuração a quantidade de dias necessários para realizar o projeto foi reduzida para 128 dias, divididos em 2 ciclos (1º Ciclo: 78 dias e 2º Ciclo: 50 dias). A Tabela 7 mostra de forma detalhada a distribuição dos dias para cada fase do processo, dentro do seu ciclo, cada ciclo é responsável pela entrega de um release. Esta abordagem em 2 ciclos foi planejada por causa da necessidade de avaliar o software em funcionamento com os usuários reais na primeira entrega. Fase Porcentagem Duração (dias) 1º Ciclo Duração (dias) 2º Ciclo Planejamento 3% 2,34 1,5 Análise e Projeto 38% 29,64 19 Codificação 19% 14,82 9,5 Testes 37% 28,86 18.5 Implantação e Treinamento 3% 2,34 1,5 Tabela - Distribuição em dias das fases do projeto 4.2 Diagrama de Gantt O Diagrama de Gantt é uma ferramenta que permite através de gráficos informar o andamento das etapas do projeto. Segundo DINSMORE e CAVALIERI (2008), trata-se de uma 22
  23. 23. relação de atividades do plano de projeto associadas a uma matriz de tempo, onde são marcadas para cada uma das atividades seu início e término. Sua facilidade de uso, o transformou em uma das ferramentas mais utilizadas para gerenciar cronogramas de atividade de projeto e seus respectivos recursos. Dentre os benefícios do seu uso, estão: ● Melhor representação do cronograma (Representação intuitiva) ● Melhor representação das atividades do projeto e seus recursos ● Melhor visualização das dependências entre as atividades ● Boa forma de avaliar os custos de tempo e recursos Na Figura 2, podemos ver o cronograma resumido das atividades do projeto, nele é mostrado apenas as etapas mais gerais do projeto e os ciclos que vão ser executados. Também é possível visualizar os recursos utilizados nas atividades, é importante ressaltar que os envolvidos participam de todas as etapas e ciclos definidos. Figura - Cronograma resumido do projeto (Diagrama de Gantt) Nas Figuras 3, observa-se o cronograma mais detalhado do projeto, onde as atividades mais especificas de cada fase são exibidas, informado seus dias e recursos necessários, além das dependências com outras atividades. 23
  24. 24. Figura - Cronograma detalhado do projeto - Diagrama de Gantt 24
  25. 25. Nas Figuras 4 e 5, são demonstradas as etapas do projeto no diagrama de Gantt. O gráfico corresponde às atividades, recursos e tempo visualizados nas imagens anteriores. Ele permite visualizar sobreposição entre atividades, fazer marcações entre trabalho planejado e realizado facilitando o acompanhamento das tarefas do projeto (DINSMORE;CAVALIERI,2008). Figura 4. Diagrama de Gantt do Projeto 25
  26. 26. Figura 5. Diagrama de Gantt do Projeto - Continuação 26
  27. 27. 5. ORGANIZAÇÃO DO PESSOAL Para uma organização desenvolver um projeto de software é necessário destinar uma equipe especializada com o contexto do projeto. Esta atividade de indicação é uma tarefa do gerente de projetos. PRESSMAN (2006) sugere que a montagem da estrutura de uma equipe depende do estilo de gestão da organização, da quantidade de pessoas que formarão a equipe e seus níveis de aptidão e da dificuldade geral do problema. No caso do projeto Remoção Interna a equipe faz parte do setor de informática da instituição sendo considerado os critérios do estilo de gestão da organização e nível de aptidão da equipe. 5.1 Estrutura da Equipe Várias atividades do projeto são conhecidas e executadas por todos os membros da equipe. Neste projeto temos o Gestor do Projeto que é o responsável por planejar, executar, acompanhar as atividades do projeto e garantir que o processo seja entendido e seguido por todos os envolvidos e os analistas, responsáveis pela modelagem e implementação dos requisitos do projeto. O projeto contará com dois analistas. 5.2 Mecanismos de Comunicação Os mecanismos de comunicação da equipe são utilizados para garantir que as informações sejam disponibilizadas de forma adequada a todos os interessados no momento oportuno. Entre os membros da equipe a comunicação pode ser formal ou informal. Os meios para comunicação formal são documentos escritos e reuniões estruturadas e para a informal uso de e-mails e encontros pessoais para troca de ideias. 5.3 Uso do Edu-blog como Ferramenta de Apoio O uso do Edu-blog mostrou-se como uma importante ferramenta de apoio nas atividades de elaboração do plano de projeto de software, já que, todos os membros podem divulgar suas atividades de forma clara e acessível, possibilitando que o conhecimento produzido seja compartilhado e difundido entre os diferentes grupos de trabalhos. 27
  28. 28. 6 PRECAUÇÕES TOMADAS PARAASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SW Algumas ações foram definidas para garantir a qualidade do produto de software, são elas: ● realização de testes de unidade; ● realização de testes de integração; ● realização de testes de interface; ● realização de testes de configuração; ● realização periódicas de revisões técnicas. 28
  29. 29. 7 REFERÊNCIAS BIBLIOGRÁFICAS —LIMA, Adilson da Silva. UML, 2.3: do requisito à solução, São Paulo: Érica, 2013. LORENZ. M, KIDD J., Object-Oriented Software Metrics, Prentice Hall, 1994. PRESSMAN, Roger S. Engenharia de software. 6ª ed. Porto Alegre: Bookman, 2006. GUIA PMBOK. Um guia do conjunto de conhecimentos em gerenciamento de projetos. 4ª ed. Pennsylvania: Project Management Institute, 2008. DINSMORE,P. C., CAVALIERI, A. Como se tornar um profissional em gerenciamento de projetos. 2a edição. QualityMark, 2008. 29

×