wp solução de gerenciamento de projetos
DESCRIPTION
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: [email protected]TRANSCRIPT
Work Plan – ProfessionalEPM – Enterprise Project Management
Portal para Gerenciamento de Projetos
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.
Estrutura Organizacional
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.
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.
• Matriz– Setor Informática
» Desenvolvimento» Infraestrutura
– Setor Fabricação» Vendas» Manufatura
• Filiais– Filial 1– Distribuidora
Hierarquia de Unidades de Projetos
– 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
– 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
– 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
– 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
– 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
– 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
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.
– 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
Templates de Projeto
Processos
Tarefas
Check-Lists
Textos Padrão
Riscos Padrão
Compromissos Padrão
EquipePadrão
–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.
– 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.
• 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.
– 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.
Templates de Projeto
Processos
Tarefas
Check-Lists
Textos Padrão
Riscos Padrão
Compromissos Padrão
EquipePadrão
• 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.
Templates de Projeto
Processos
Tarefas
Check-Lists
Textos Padrão
Riscos Padrão
Compromissos Padrão
EquipePadrão
• 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.
– 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
– 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.
– 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.
– 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.
• 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.
Templates de Projeto
Processos
Tarefas
Check-Lists
Textos Padrão
Riscos Padrão
Compromissos Padrão
EquipePadrão
• 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.
• 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’.
Templates de Projeto
Processos
Tarefas
Check-Lists
Textos Padrão
Riscos Padrão
Compromissos Padrão
EquipePadrão
– 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.
Templates de Projeto
Processos
Tarefas
Check-Lists
Textos Padrão
Riscos Padrão
Compromissos Padrão
EquipePadrão
– 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.
Produtos
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).
– 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
– 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
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
Tipos de Objetos
Clarion Browse Clarion MainClarion ReportClarion SelectClarion SourceClarion SplashClarion UpdateClarion Window Crystal Reports – Relatório Dreamweaver CSS
Tipos de Requisitos
CadastrosConsultasConversãoImportaçãoProcessosRelatórioRequisitos Não Contemplados
Enquadramentos
ComplexoMuito ComplexoNormalSimples
– 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
– 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
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>
– 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.
Exemplo de Registro de Alteração
Projeto 15
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
Projeto 18
• Controle de Aprovações• Controle de check-out e check-in dos arquivos• Controle para Atualização de Clientes
Módulo de Solicitações
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
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çãopara Execução
Desistência da solicitação
Deficiência de Informações
Entendimentode escopo
Necessidade de projeto
Necessidade de projeto
Entrega doProjeto
Tarefa executada
Tarefaexecutada
NecessidadeAtendida
SoluçãoAceita
Necessidadenão Atendida
Problemade escopo
Documentaçãodo problema
Criação daSolicitaçãoCriação da
Solicitação
Fechada
Cancelada
FLUXO DE ATENDIMENTO DE SOLICITAÇÕES
Solicitante
Atendimento
Equipe Projeto
Re
spo
nsa
bilid
ad
e
Gerenciamento de Projetos
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
RiscosRecursosTextosAnexos
– 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
• 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
Consultas e Relatórios
Detalhamento do Projeto
Alocação de Recursos / Equipe
Painel Projetos
– Acompanhamento Projeto– Cronograma– Atividades – Tarefas– Painel Check-Lists
Relatórios
– Plano de Projeto– Escopo– Especificação Funcional– Textos do Projeto– Cronograma do Projeto– Atividades– Despesas do Projeto– Despesas Responsável
Módulo de Homologação
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.
Controle Físico e Lógico
Processo de controle de versão dos
produtos desenvolvidos em projetos
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)
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.)
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
– 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>
– 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.
Projeto 15
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
Projeto 18
• Controle de Aprovações• Controle de check-out e check-in dos arquivos• Controle para Atualização de Clientes
– 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
– 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
Pacotes de Atualização
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.
– 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.
– 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
– 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
– 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.
Geração de Pacotes de Atualização nos Clientes
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.
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:
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.
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
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
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.
Seqüência de Geração dos Objetos
– A seqüência de geração dos objetos dentro do pacote será conforme abaixo:1. Tipo de objeto
2. Definição (data que a mesma foi entrega)
3. Ordem dentro da Definição
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.
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
– 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
– 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.
Indicadores
Lançamento
Pontualidade
Desempenho
Eficácia
Produtividade
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%
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%
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%
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%
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%
Análise de Indicadores
– Consulta de Indicador e Período por:
• Unidade de Projetos
• Responsável (colaborador)
• Cliente
• Tarefa
Unidade de Projetos
Responsável / Cliente / Tarefa
Lançamento
Responsável / Cliente / Tarefa
Pontualidade
Análise por Períodos
Lançamento
– 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