Your SlideShare is downloading. ×
0
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
WP Solução de Gerenciamento de Projetos
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

WP Solução de Gerenciamento de Projetos

894

Published on

Ferramenta de Gerenciamento de Projetos completa fornaciado pela ADVN Soluções de TI e Software Corporativo, empresa certificada ISO 9001:2008 em 2010. Além nisso existe o módulo de solicitação para …

Ferramenta de Gerenciamento de Projetos completa fornaciado pela ADVN Soluções de TI e Software Corporativo, empresa certificada ISO 9001:2008 em 2010. Além nisso existe o módulo de solicitação para atender demandas específicas do cliente.
Mais informações: comercial@advn.com.br

Published in: Business, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
894
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
16
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Work Plan – Professional EPM – Enterprise Project Management Portal para Gerenciamento de Projetos
  • 2.  
  • 3. WP - Professional
      • Ferramenta completa para o Gerenciamento de Projetos, incluindo projetos de desenvolvimento de software .
          • Abrange todo o ciclo de vida do projeto.
          • Atende as melhores práticas de desenvolvimento de software e de gerenciamento de projetos, descritas no CMMI, MPS.BR e PMBOK.
  • 4. Estrutura Organizacional
  • 5. Conceitos
      • Unidade de Projetos
        • Utilizadas para identificar as diversas equipes de projetos da empresa. Mantendo informações distintas das equipes, produtos, processos e projetos.
      • Papéis
        • Identifica os papéis que são exercidos na organização e nos projetos.
      • Responsáveis
        • Cadastro que contém todas as pessoas que terão acesso ao sistema.
  • 6. Conceitos
      • O acesso às funcionalidades do sistema é definido no módulo do Administrador do Sistema, conforme os papéis que cada responsável desempenha na organização. O acesso aos projetos é definido na equipe do projeto e também pelos papéis dos responsáveis.
  • 7.
        • Matriz
          • Setor Informática
            • Desenvolvimento
            • Infraestrutura
          • Setor Fabricação
            • Vendas
            • Manufatura
        • Filiais
          • Filial 1
          • Distribuidora
    Hierarquia de Unidades de Projetos
  • 8.
      • Processos
        • Os projetos poderão herdar os processos da unidade definida no projeto ou de unidades de níveis superiores
      • Exemplo:
        • Projeto criado para a Unidade Setor Fabricação poderá utilizar processos da Manufatura
        • “ Manufatura” - poderá utilizar processo somente de “Manufatura”
    Hierarquia de Unidades de Projetos
  • 9.
      • Equipe
        • Poderão ser alocados recursos em projetos de qualquer unidade dentro no mesmo nível hierárquico (1º. Nível) da unidade definida no projeto.
      • Exemplo: Um projeto do Desenvolvimento poderá alocar qualquer responsável que esteja abaixo da Matriz (Inclusive)
      • Responsável da Solicitação vale a mesma regra!
    Hierarquia de Unidades de Projetos
  • 10.
      • Acesso – Consultas e Relatórios
        • O usuário poderá acessar somente projetos da sua unidade ou de unidades de níveis inferiores, ou de unidades que o mesmo estiver cadastrado na equipe.
      • Exemplo: Responsável do Desenvolvimento poderá consultar projetos do Desenvolvimento e para outra unidade somente se estiver cadastrado na equipe do projeto.
    Hierarquia de Unidades de Projetos
  • 11.
      • Produtos
        • Os projetos poderão alterar produtos da unidade definida no projeto ou produtos de unidades de níveis Inferiores.
      • Exemplo:
        • Setor Informática poderá alterar somente produtos do Setor Informática, Desenvolvimento e Infra-Estrutura.
    Hierarquia de Unidades de Projetos
  • 12.
      • Projetos – Manutenção
        • Somente a equipe do projeto poderá ter acesso a manutenção do projeto (não muda nada nisso)
        • Conforme permissão de acesso da equipe
          • Planejamento
          • Especificação
          • Definição
          • Informações
        • Inclui execução de testes e painel de checklist.
    Hierarquia de Unidades de Projetos
  • 13.
      • Orçamentos:
        • Manutenção de Consulta
          • Conforme a Unidade o usuário logado com acesso nos níveis Inferiores
      • Contratação:
        • Templates
          • Poderá assumir templates de Unidades de níveis superiores. Inclui somente para a Unidade em que está cadastrado.
        • Aprovações
          • Buscar o responsável pela aprovação da mesma unidade ou de unidades de níveis superiores.
    Hierarquia de Unidades de Projetos
  • 14. Estrutura Organizacional
    • Responsáveis
    • Joaquim
    • Ana
    • Pedro
    • André
    • João
    • Vilma
    • Vilson
    • Papéis
    • Gerente de Fábrica
    • Coordenador de Unidade
    • Programador
    • Gerente de Projeto
    • Analista
    • Suporte de Sistemas
    • Suporte de Infra-Estrutura
    As permissões dos menus e funções nos projetos são definidas de acordo com os papéis dos responsáveis.
  • 15.
      • Os templates de projeto são a base dos processos da organização
      • Documentam os principais processos e tarefas das equipes, de acordo com cada tipo de projeto
    Templates de Projeto
  • 16.  
  • 17.
      • Templates:
        • São os tipos distintos de processos da organização
        • Cada projeto é vinculado a um template
        • Os dados do projeto são criados conforme a configuração do template de projeto.
  • 18.
      • Planejamento
        • Com aprovação – Exige que o planejamento seja aprovado antes do fechamento do projeto
        • Sem Aprovação – Não exige aprovação do planejamento.
        • Aprovação do planejamento do projeto somente pode ser realizada por usuário que possua um papel que permita a aprovação do planejamento de um projeto.
  • 19.
    • Especificação
      • Não requer – Projeto não precisa ter especificação de requisitos
      • Sem aprovação – Exige a criação de uma especificação de requisitos, mas não precisa estar aprovada
      • Com Aprovação – Exige que a especificação de requisitos esteja aprovada para o fechamento do projeto
    • Aprovação da especificação de requisitos do projeto somente pode ser realizada por usuário que possua um papel que permita a aprovação de especificações de um projeto.
  • 20.
      • Definição
        • Não requer – Projeto não precisa ter uma definição funcional
        • Sem aprovação – Exige a criação de uma definição funcional, mas não precisa estar aprovada
        • Com Aprovação – Exige que as definições funcionais criadas para o projeto estejam aprovadas para o fechamento do projeto
        • Com Homologação – Além das definições funcionais estarem aprovadas elas devem ter sido devidamente homologadas antes do fechamento do projeto
      • Aprovação da definição funcional somente pode ser realizada por usuário que possua um papel que permita a aprovação de definições.
  • 21.  
  • 22.
        • São as fases de um projeto
        • Podem ser criados com múltiplos níveis, vinculando um processo pai a cada filho criado
        • Processo obrigatório – É criado automaticamente no momento da criação do projeto
        • Processo opcional – Não é criado junto da criação do projeto mas pode ser utilizado no planejamento do projeto.
  • 23.  
  • 24.
        • São as tarefas para execução de cada processo
        • São trazidas da base de tarefas da organização
        • Serão trazidas pelo sistema no momento em que o Gerente de Projeto estiver planejamento o processo, após a criação do projeto.
  • 25.
      • Dados gerais do cadastro de tarefas:
        • Unidade – Unidade onde é realizada esta tarefa.
        • Cronograma – Se imprime ou não a tarefa nos relatórios de cronograma ou plano de projeto
        • Tipo de lançamento
          • Detalhado – O registro de horas é baseado em lançamentos detalhados e o sistema calcula o esforço total da tarefa:
            • 19/04/2007 – 10:00 às 11:00
            • 20/04/2007 – 08:00 às 12:00
          • Acumulado – Para esta tarefa é registrado somente o volume total de esforço realizado, independentemente do período de execução:
            • 10 horas realizadas na tarefa
  • 26.
      • Dados gerais do cadastro de tarefas:
        • Forma de utilização
          • Projeto – Tarefa somente pode ser utilizada em Templates de projeto e posteriormente em Projetos
          • Manual – Tarefa para lançamento de atividades avulsas
          • Solicitação – Tarefa para lançamento de atividades em atendimento de solicitações
        • Altera descrição
          • Se estiver marcada, o GP poderá alterar a descrição da tarefa no seu projeto, senão deve seguir conforme registrado no processo.
        • Papel
          • Papel que pode executa a tarefa. A tarefa somente poderá ser atribuída a responsáveis que possuem o papel designado para a tarefa.
  • 27.
      • Dados da tarefa no processo:
        • Ordem de execução da tarefa
        • Obrigatoriedade da tarefa
          • Opcional – Não é criada automaticamente e pode ser trazida do processo pelo GP
          • Normal – É criada automaticamente e pode ser excluída pelo GP
          • Obrigatória – É criada automaticamente e não pode ser excluída pelo GP.
  • 28.
      • Dados da tarefa no processo:
        • Previsto – Tempo padrão da tarefa neste processo. Informado como orientação no processo com possibilidade de alteração do GP no projeto.
        • Percentual – Percentual do tempo total de requisitos do projeto
          • Exemplo: A análise será de 20% do tempo total de desenvolvimento. O tempo de desenvolvimento deverá ser informado no tempo de requisitos do projeto.
  • 29.
        • Dados da tarefa no processo:
          • Dependências
            • Definição das dependências padrão do processo. Pode ser ajustado pelo GP no projeto.
          • Anexos
            • Definição dos templates da organização para execução da tarefas. Podem ser baixados pelo executor no momento da realização da tarefa e posteriormente anexados ao projeto.
  • 30.  
  • 31.
        • Itens de checagem para fechamento de uma tarefa.
        • Caso uma tarefa possua check-list associado, ela somente poderá ser concluída quando o check-list for preenchido.
        • Podem ser associados mais de um check-list para uma tarefa. O executor deverá selecionar um dos check-lists associados para o seu preenchimento.
  • 32.
        • Cada item de check-list possuirá uma ordem de teste e uma classificação de gravidade de erro quando for encontrado.
        • O valor atribuído ao peso da uma classificação é somado ao total de não-conformidades encontrados em um projeto. Naqueles itens que foram diferentes de ‘Conforme’.
  • 33.  
  • 34.
      • Textos
        • Associação de textos padrão que são registrados no projeto (emails ou registro de telefonemas, por exemplo).
      • Riscos e Compromissos
        • No cadastro são chamados de Eventos. Registram os tipos de riscos e compromissos/recursos padrão.
        • São criados automaticamente no momento da criação do projeto para serem qualificados e mantidos pelo GP.
  • 35.  
  • 36.
      • Papéis e Responsáveis
        • São registrados todos os papéis que podem fazer parte de um projeto deste tipo.
        • Caso exista algum responsável único para o papel, pode ser definido diretamente no template, por exemplo: Gerente de Desenvolvimento, Garantia de Qualidade, Diretor Sênior.
  • 37. Produtos
  • 38. Conceitos
      • Produtos
        • Identifica os produtos que serão controlados pelo sistema. Serão mantidos através dos projetos.
        • Exemplo:
          • Sistema de ERP
          • Projeto do Portal de Fornecedores
          • Projeto de Construção do Aeroporto
      • Módulos
        • É uma sub-divisão dos produtos utilizada para facilitar o acesso e o controle dos mesmos (áreas).
  • 39.
      • Objetos
        • É o nível mais baixo de controle. Irá conter os fontes dos produtos do projeto (programas, desenhos, plantas, etc.)
        • O sistema irá fazer o controle de versão individualmente para cada objeto alterado nos projetos. Exemplo:
          • Objeto X
            • Versão 1.1
            • Versão 1.1.1 – Sub-versão, versão intermediária
            • Versão 1.2
          • Objeto Y
            • Versão 1.1
            • Versão 1.2
            • Versão 1.3
    Conceitos
  • 40.
      • Requisitos
        • Funcionalidades ou requisitos funcionais que compõem o produto/módulo.
        • Através da associação entre requisitos e objetos é possível manter a rastreabilidade de alterações das funcionalidades realizadas nos projetos.
    Conceitos
  • 41. Produtos
    • Produtos
    • Gestor
    • Salutar
    • Educar
    • Gespam
    • Módulos
    • Água
    • Almox
    • Bolão
    • Dívida
    • Objetos
    • Acerto Geral
    • Agua_SQL
    • AlterTable_Agua
    • Requisitos
    • Manutenção de Água
    • Manutenção de Almox
    • Cadastro de Dívida
  • 42. Tipos de Objetos Clarion Browse Clarion Main Clarion Report Clarion Select Clarion Source Clarion Splash Clarion Update Clarion Window Crystal Reports – Relatório Dreamweaver CSS Tipos de Requisitos Cadastros Consultas Conversão Importação Processos Relatório Requisitos Não Contemplados Enquadramentos Complexo Muito Complexo Normal Simples
  • 43.
      • Definição (Projeto – Definições)
        • Identifica um pacote de alteração em objetos para um determinado projeto.
        • Uma definição poderá conter somente um ou mais objetos.
        • A versão do objeto é única, independente de definição.
        • O sistema permite configurar:
          • Se a definição precisa de aprovação para iniciar a execução.
          • Se precisa de aprovação (homologação) para entregar ao cliente.
    Conceitos
  • 44.
      • Especificação (Projeto - Escopo)
        • Identifica o escopo do produto que será desenvolvido no projeto, formado por requisitos (funcionalidades).
        • Um projeto poderá conter somente um escopo aprovado. É possível fazer a alteração do escopo inicial, mas mantêm-se o controle de alteração.
    Conceitos
  • 45. Controle de Versão / Alteração
      • O sistema executa o controle de versão a nível de objeto. Exemplo:
        • Objeto: Planta Baixa Escola “A”
          • Versão 1.1
            • Objeto criado no Projeto 15
          • Versão 1.2
            • Objeto alterado no Projeto 18
            • <registro de todos os dados de alteração>
          • Versão 1.3
            • Objeto alterado no Projeto 22
            • <registro de todos os dados de alteração>
  • 46.
      • Para criar ou alterar um objeto (componente de um produto) é necessário criar uma “Definição” dentro de um projeto.
        • Um objeto poderá estar em alteração em uma única definição (versão), após poderá ser criado uma nova versão em outro projeto, gerando o registro das alterações e armazenando os arquivos físicos de cada versão.
  • 47. Exemplo de Registro de Alteração Projeto 15 Projeto 18
    • Controle de Aprovações
    • Controle de check-out e check-in dos arquivos
    • Controle para Atualização de Clientes
    Definição I
    • Objeto “A” v1.0
    • Objeto “B” v1.0
    • Objeto “C” v1.1
    Definição II
    • Objeto “A” v1.1
    • Objeto “D” v1.3
    Definição I
    • Objeto “A” v1.3
    • Objeto “B” v1.1
    • Objeto “D” v1.4
  • 48. Módulo de Solicitações
  • 49. Solicitações
    • Parceiros criam solicitações.
    • Suporte Cadastram solicitações de Clientes.
    • Priorização das solicitações.
    • Geração de projetos a partir de uma solicitação.
    Canal de Comunicação
  • 50. FLUXO DE ATENDIMENTO DE SOLICITAÇÕES Necessidades / Problemas Lixeira Incluída Rascunho Em Aprovação Aprovada Entregue Devolvida Em Atendimento Projeto Deficiência de Informações Complemento de Informações Solicitação de Aprovação Proposta não Aceita Proposta Aceita Solicitação de Aprovação para Execução Desistência da solicitação Deficiência de Informações Entendimento de escopo Necessidade de projeto Necessidade de projeto Entrega do Projeto Tarefa executada Tarefa executada Necessidade Atendida Solução Aceita Necessidade não Atendida Problema de escopo Documentação do problema Criação da Solicitação Criação da Solicitação Fechada Cancelada Solicitante Atendimento Equipe Projeto Responsabilidade
  • 51. Gerenciamento de Projetos
  • 52. Projeto
    • Projeto
    • Unidade
    • Template
    • Cliente
    • Prioridade
    • Classificação
    • Responsável
    • Objetivo
    • Equipe
    • Responsável
    • Papel
    • Permissões
    • Processo
    • Processos - Fases
    • Tarefas
    • Tempos
    • Datas
    • Definição
    • Objetos (Análise)
    • Especificação
    • Requisitos
    Riscos Recursos Textos Anexos
  • 53.
      • Planejamento:
        • Cálculo do Cronograma do Projeto
        • Aprovação do Planejamento do Projeto
        • Liberação de Projetos
      • Aprovação/Substituição Escopo
      • Aprovação/Homologação/Entrega/Cancelamento de Definição
  • 54.
    • Lançamento de Atividades que não estão relacionados a nenhum projeto.
      • Outras Atividades
      • Reunião sem Projeto
      • Auxílio a Equipe de Suporte
      • Ausência
    • Lançamento de Despesas que não estão relacionadas a nenhum projeto.
      • Alimentação
      • Deslocamento
      • Hospedagem
      • Ingressos em Eventos
      • Treinamentos
  • 55. Consultas e Relatórios
  • 56.
    • Detalhamento do Projeto
  • 57.
    • Alocação de Recursos / Equipe
  • 58.
    • Painel Projetos
  • 59.
      • Acompanhamento Projeto
      • Cronograma
      • Atividades
      • Tarefas
      • Painel Check-Lists
  • 60. Relatórios
      • Plano de Projeto
      • Escopo
      • Especificação Funcional
      • Textos do Projeto
      • Cronograma do Projeto
      • Atividades
      • Despesas do Projeto
      • Despesas Responsável
  • 61. Módulo de Homologação
  • 62. Homologação
      • Testes Unitários (definição)
        • Cadastrados na definição do projeto. Pode-se executá-los e caso necessário criar tarefas de testes ou correção.
      • Plano de Teste (produto)
        • Cadastrados no sistema e vinculados a produtos e/ou módulos.
        • São mais genéricos, utilizados para testar os produtos na sua totalidade.
  • 63.
      • Controle Físico e Lógico
    Processo de controle de versão dos produtos desenvolvidos em projetos
  • 64. Objetivos do Processo
      • Detalhar o processo de controle dos produtos gerenciados pelo sistema
      • Controlar o acesso físico e lógico dos artefatos dos produtos (arquivos fontes)
      • Manter o histórico de alterações nos produtos e permitir recuperar versões anteriores dos mesmos
      • Controlar envio de atualizações para os clientes
        • Novos produtos
        • Alterações em produtos
        • Vinculado a parte financeira (Contratos)
  • 65. Conceitos do Sistema
      • Produtos
        • Identifica os produtos que serão controlados pelo sistema. Serão criados ou atualizados através dos projetos.
      • Módulos
        • É uma sub-divisão dos produtos utilizada para facilitar o acesso e o controle dos mesmos.
      • Objetos
        • É o nível mais baixo de controle do produto.
        • Irá conter os fontes dos produtos do projeto (programas, desenhos, plantas, etc.)
  • 66. Exemplo de Relacionamento
    • Produtos
    • Projetos Prefeitura
    • Projeto Aeroporto
    • Módulos
    • Projeto Escola “A”
    • Projeto Reforma praça
    • Objetos
    • Planta Baixa
    • Planta hidráulica
    • Planta Elétrica
  • 67.
      • O sistema executa o controle de versão a nível de objeto.
      • A versão do objeto somente poderá ser criada (gerada) através de um projeto.
      • Exemplo:
        • Objeto: Planta Baixa Escola “A”
          • Versão 1.1
            • Objeto criado no Projeto 15
          • Versão 1.2
            • Objeto alterado no Projeto 18
            • <registro de todos os dados de alteração>
          • Versão 1.3
            • Objeto alterado no Projeto 22
            • <registro de todos os dados de alteração>
  • 68.
      • Para criar ou alterar um objeto (componente de um produto) é necessário criar uma “Definição” dentro de um projeto.
        • A Definição do Projeto representa um conjunto de alterações em objetos.
        • O sistema permite parametrizar:
          • Se a definição precisa de aprovação para iniciar a execução.
          • Se precisa de aprovação (homologação) para entregar ao cliente.
        • Um objeto poderá estar em alteração em uma única definição (versão), após poderá ser criado uma nova versão em outro projeto, gerando o registro das alterações e armazenando os arquivos físicos de cada versão.
  • 69. Projeto 15 Projeto 18
    • Controle de Aprovações
    • Controle de check-out e check-in dos arquivos
    • Controle para Atualização de Clientes
    Definição I
    • Objeto “A” v1.0
    • Objeto “B” v1.0
    • Objeto “C” v1.1
    Definição II
    • Objeto “A” v1.1
    • Objeto “D” v1.3
    Definição I
    • Objeto “A” v1.3
    • Objeto “B” v1.1
    • Objeto “D” v1.4
  • 70.
      • Cliente
        • Contrato (negociação)
          • Produtos Contratados
      • Geração de Pacotes de Atualização por Cliente
        • Cliente “A”
          • Pacote 1
            • Objeto “A” v1.0
            • Objeto “B” v1.0
            • Objeto “C” v1.1
          • Pacote 2
            • Objeto “A” v1.1
  • 71.
      • O controle de acesso é parametrizado por Papel (perfil)
      • Exemplo:
        • Gerente de Projetos
          • Aprova Definição
          • Libera Entrega para o Cliente
        • Arquiteto
          • Altera Definição (cria versão do objeto)
          • Aprova alteração da versão
        • Desenhista
          • Altera o objeto gerando nova versão
  • 72. Pacotes de Atualização
  • 73. Objetivos a Serem Alcançados
      • Atender o processo de controle das atualizações dos produtos nos clientes, através de:
        • Versão de produto (release)
        • Sub-versão de produtos ( patch)
      • Manter informações dos calendários de entrega das versões dos produtos
      • Controlar as alterações em produtos e projetos que farão parte de cada versão liberada.
  • 74.
      • Produtos
        • Identifica os produtos que serão controlados pelo sistema. Serão mantidos através dos projetos.
        • Exemplo:
          • Sistema de ERP
          • Projeto do Portal de Fornecedores
          • Projeto de Construção do Aeroporto
      • Módulos
        • É uma sub-divisão dos produtos utilizada para facilitar o acesso e o controle dos mesmos.
  • 75.
      • Objetos
        • É o nível mais baixo de controle. Irá conter os fontes dos produtos do projeto (programas, desenhos, plantas, etc.)
        • O sistema irá fazer o controle de versão individualmente para cada objeto alterado nos projetos. Exemplo:
          • Objeto X
            • Versão 1.1
            • Versão 1.1.1 – Sub-versão, versão intermediária
            • Versão 1.2
          • Objeto Y
            • Versão 1.1
            • Versão 1.2
            • Versão 1.3
  • 76.
      • Definição (Projeto – Definições)
        • Identifica um pacote de alteração em objetos para um determinado projeto.
        • Uma definição poderá conter somente um ou mais objetos.
        • A versão do objeto é única, independente de definição.
        • Terá o controle de bloqueio de alteração e o controle de check-in e check-out
  • 77.
      • Atualização Produtos
        • Identifica o controle de geração de pacotes para atualização de determinados produtos. Exemplo:
          • Atualização dos produtos de Engenharia
          • Atualização dos produtos de Projetos de Software
      • Calendário Atualização
        • Os calendários estarão associados a uma “Atualização Produtos” e poderão ser definidos dois tipos de calendário:
          • Nova Versão ou Release
            • Identifica uma atualização de uma nova versão dos produtos
          • Correções ou Patch
            • Identifica uma sub-versão que é liberada entre uma versão e outra dos produtos para correção de problemas.
      • Importante: A versão dos produtos é diferente da versão dos objetos. Em uma mesma versão do produto poderão existir mais de uma versão de um objeto.
  • 78. Geração de Pacotes de Atualização nos Clientes
  • 79. Calendário Atualização
      • O “Calendário Atualização” (versão) será definido pelo usuário responsável pelas atualizações dos produtos nos clientes (SCM).
      • A seqüência do calendário de atualização será por data de entrega ou fechamento do pacote.
      • O Calendário possuirá um indicador se é uma versão do produtos (Release) ou uma sub-versão (patch)
      • O usuário informará a versão dos produtos que estarão sendo liberadas no calendário
          • Exemplo: v.1.0.1 - v.1.0.1.1 - v.1.0.2
      • O Calendário terá informações de datas de entrega das definições e de geração do pacote de atualização.
  • 80. Controle de Alteração dos Produtos
      • Na definição do projeto deverá ser informado o “Calendário Atualização” para os produtos que possuem controle de atualização através de calendário.
        • Se não informado “Calendário Atualização” na definição, não poderá ser informado objetos.
        • Não poderá gerar versão
      • O Calendário irá identificar a Release ou patch que será gerada dos produtos:
  • 81. Geração do Pacote
    • O sistema irá apresentar para a “Atualização Produtos” os “Calendários Atualização”, com geração em aberto.
      • Terá um indicador de definição entregue ou não
      • Uma definição não entregue não poderá ser gerada no pacote de atualização.
    • O SCM poderá marcar as definições que serão geradas na data.
    • Após a geração do pacote não poderão ser incluída novas definições para o calendário.
    • Para as definições não geradas, deverá ser alterado o “Calendário Atualização”
    • O “Calendário Atualização” poderá ter gerações parciais ou ser cancelado.
  • 82. Objeto “C”: Não possuía versão em aberto e foi gerada a versão 7 e será acrescentada na Release 17. Objeto “D”: a versão 2.2 foi criada após a liberação da versão 3 do objeto, será necessário criar a versão 4 para incorporar as alteração realizadas. Objeto “E”: A versão 7 foi criada após a conclusão da versão do produto V17 (analisar se é necessário).NÃO Objeto V 15 V 16 V 16.1 V 16.2 V 17 A - 2 2.1 2.2 3 B 4 4.1 5 C 6 7 -> 7 D - 2 2.1 2.2 3 -> 4 E 6 7 -> 7 -> 8
  • 83. Controle de Pacotes por Cliente
      • Atualização para o Cliente A
        • Do pacote da versão 15 para a 17
          • Serão enviadas as versões 16, 17 e mais os patches da versão 17
        • Na geração do “Calendário Atualização” o sistema continuará gerado um pacote individual para cada cliente, levando em consideração os produtos e módulos por ele contratados.
      • Observação:
        • Serão excluídas as versões dos objetos de Release e patches antigos, mantendo somente as duas últimas versões do objeto que já foram entregues para todos os clientes.
  • 84. Seqüência de Geração dos Objetos
      • A seqüência de geração dos objetos dentro do pacote será conforme abaixo:
        • Tipo de objeto
        • Definição (data que a mesma foi entrega)
        • Ordem dentro da Definição
  • 85. Pacote Especial
      • O sistema irá permitir a geração de um pacote especial, a partir de definições dos projetos, para envio a um cliente para testes e homologação.
      • Na geração normal do “Calendário Atualização” essa definição estará disponível e será gerada novamente para o cliente.
  • 86. Configuração de e-mails
      • O sistema irá permitir configurar e-mails para esse processo nos seguintes critérios:
        • Alteração de “Calendário Atualização”
          • Aviso de definição alterada de calendário
          • Para: Gerente de projetos ou analistas e SCM
        • Geração do “Calendário Atualização”
          • Aviso de “Atualização Produtos”
          • Para: Usuário Chaves, Clientes
  • 87.
      • Produtos
        • Identificar os produtos que terão controle de entrega por Release e patch ( associados a uma Atualização Produtos)
      • Objetos
        • Criar tabela para armazenar os documentos físicos dos objetos.
        • Será armazenado um arquivo por versão.
        • Por tipo de Objeto:
          • Identificar os objetos que serão gerados nos pacotes.
          • Identificar os objetos com bloqueio de versão dos objetos.
          • Controle de check-in e check-out pelo sistema
      • Criar tabelas para armazenar as informações de Atualização Produtos e Calendário Atualizações
  • 88.
      • Como enviar uma definição e todas as suas dependências, sem enviar todo o pacote?
        • A relação dos objetos é por definição!
        • Não poderá enviar o mesmo objeto em duas entregas diferentes!
      • Os patches devem ser “filhos” da release e quando buscar uma versão para o pacth deverá buscar a versão entregue na release. Mesmo tendo uma release mais a frente. Servirá para corrigir um erro daquela versão.
      • Criar arquivos anexos a definição para acrescentar scripts de menus, parâmetros e outros. Poderá ser anexo a objeto sem controle de versão, irá junto com a definição.
      • O Nome físico do objeto não depende do nome do objeto.
  • 89. Indicadores
  • 90.
    • Lançamento
    • Pontualidade
    • Desempenho
    • Eficácia
    • Produtividade
  • 91. Lançamento
      • Indicador:
        • Horas disponíveis / Horas lançadas
        • Considera o calendário da unidade e o calendário individual.
      • Objetivo:
        • Acompanhar o volume de horas lançadas no sistema
      • Meta: 100 %
      • Exemplo:
        • Horas disponíveis 1000
        • Horas lançadas 950
        • Indicador de lançamento 95%
  • 92. Pontualidade
      • Indicador:
        • Total de tarefas entregues / tarefas entregues no prazo
      • Objetivo:
        • Acompanhar a pontualidade na entrega das tarefas
      • Meta: ??? %
      • Exemplo:
        • Total de tarefas: 10
        • No prazo: 8
        • Indicador de Pontualidade: 80%
  • 93. Desempenho
      • Indicador:
        • Esforço planejado / Esforço realizado
      • Objetivo:
        • Acompanhar o desempenho da equipe e as estimativas do projeto.
      • Meta: ??? %
      • Exemplo:
        • Horas planejadas: 10, Horas executadas: 8 = 125%
        • Horas planejadas: 10, Horas executadas: 10 = 100%
        • Horas planejadas: 10, Horas executadas: 12 = 83%
  • 94. Eficácia
        • Indicador:
          • Horas trabalhadas em projetos normais X projetos de correção
        • Objetivo:
          • Acompanhar o índice de re-trabalho gerados pelos projetos.
        • Meta: ??? %
        • Exemplo:
          • Horas totais de projeto: 100
          • Horas em projetos de correção: 12
          • Indicador de Eficácia: 82%
  • 95. Produtividade
        • Indicador:
          • Total de horas trabalhadas X horas em projetos “produtivos”
        • Objetivo:
          • Acompanhar os trabalhos e direcionas os trabalhos para projetos “produtivos” para a organização
        • Meta: ??? %
        • Exemplo:
          • Horas trabalhadas: 1000
          • Horas em Projeto: 600
          • Indicador Produtividade: 50%
  • 96. Análise de Indicadores
      • Consulta de Indicador e Período por:
        • Unidade de Projetos
        • Responsável (colaborador)
        • Cliente
        • Tarefa
  • 97. Unidade de Projetos
  • 98. Responsável / Cliente / Tarefa Lançamento
  • 99. Responsável / Cliente / Tarefa Pontualidade
  • 100. Análise por Períodos Lançamento
  • 101.
      • O controle de acesso é parametrizado por Papel (perfil)
      • Exemplo:
        • Gerente de Projetos
          • Aprova Definição
          • Libera Entrega para o Cliente
        • Arquiteto
          • Altera Definição (cria versão do objeto)
          • Aprova alteração da versão
        • Desenhista
          • Altera o objeto gerando nova versão
    Administrador do Sistema

×