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