wiki:Guias/ExecucaoProcesso
Last modified 7 years ago Last modified on 07/03/12 16:51:18

Guia de Execução do Processo

  1. Guia de Execução do Processo
  2. SUMÁRIO
  3. Apresentação
    1. Perguntas Frequentes
      1. O que é o Guia de Execução do Processo?
      2. Como utilizar este guia?
      3. Quando utilizar este guia?
      4. Quem deve utilizar este guia?
  4. Alocação de Recursos
    1. Recursos Humanos
    2. Recursos Materiais
      1. Ambiente de Trabalho
      2. Aquisição de Equipamentos
      3. Outras Aquisições
  5. Banco de Demandas
    1. Organização do Banco de Demandas
      1. Milestone "não-planejado"
      2. Milestone "interrompido"
    2. Registro de uma demanda
      1. 1. Criar novo Ticket (Registrar Demanda)
      2. 2. Registrar a Declaração Formal de Demanda em página wiki (Detalhar …
  6. Banco de Mudanças
    1. Organização do Banco de Mudanças
      1. 1. Registrar o ticket da Solicitação de Mudança no Banco de Mudanças
      2. 2. Registrar a Solicitação de Mudança em página wiki
      3. 3. Encerrar Ticket
  7. Ciclo de Vida
    1. Modelo de Desenvolvimento
    2. Fases
      1. Gerenciamento
      2. Execução
      3. Lançamento
      4. Aquisição
      5. Monitoramento
      6. Mudança
    3. Esforço
    4. Entregáveis
  8. Comunicação
  9. Cronograma de Execução
  10. Estimativas do Projeto
    1. Priorização de Demandas
    2. Estimativa de Tamanho
      1. Apresentação do método
      2. Definição do método
        1. Definição das Funções
          1. Tipo Dado
          2. Tipo Transação
        2. Tabelas de referência
      3. Preenchimento do template
      4. Tamanho do Projeto
    3. Estimativa de Esforço
    4. Estimativa de Custo
  11. Itens de Ação
    1. Abertura de Tickets
      1. Aceite
    2. Realização das atividades
    3. Encerramento de Tickets
  12. Processo de Aquisição
    1. Ticket de Aquisição de Demanas
    2. Ticket de Monitoramento da Aquisição
  13. Rastreabilidade
    1. Links de rastreabilidade
      1. Definir e Manter Matriz de Rastreabilidade (Fase de Gerenciamento)
        1. Documento [Declaração Formal de Demanda]
      2. Atualizar Matriz de Rastreabilidade (Fase de Execução)
        1. Documento [Declaração Formal de Demanda]
        2. Documento [Plano de Projeto]
        3. Documento [Especificação das Demandas]
      3. Atualizar Matriz de Rastreabilidade (Processo de Mudança)
    2. Estrutura da Matriz de Rastreabilidade
    3. Atividade [Definir e Manter Matriz de Rastreabilidade] (Fase de …
    4. Atividade [Atualizar Matriz de Rastreabilidade] (Fase de Execução)
    5. Atividade [Aprovar Codificação das Demandas] (Fase de Execução)
    6. Atividade [Atualizar Matriz de Rastreabilidade] (Processo de Mudança)
  14. Riscos e Viabilidade
  15. Seleção de Demandas
    1. Acesso ao Banco de Demandas
    2. Análise e seleção
      1. Ordem de análise

SUMÁRIO

Apresentação

Este é o Guia de Execução do Processo. O guia deve ser consultado todos os momentos que for julgado necessário pelos executantes do Processo de Densenvolvimento da Prognus Software Livre.

Aqui são listados procedimentos relacionados à manipulação de ferramentas, metodologias de estimativas e avaliação e definições padrão do processo. O Guia está dividido em seções, onde cada seção atende a uma ou mais atividades do processo quando executadas.

Se esta for a primeira vez utilizando o guia, é recomendável a leitura das Perguntas Frequentes abaixo para uma melhor compreensão e utilização do guia.

Perguntas Frequentes

Abaixo são respondidas algumas perguntas fundamentais acerca da utilização do Guia de Execução do Processo:

O que é o Guia de Execução do Processo?

É o documento oficial de auxílio e consulta para execução do Processo de Desenvolvimento da Prognus Software Livre. Este guia foi definido em paralelo ao Processo de Desenvolvimento da Prognus Software Livre e visa complementar o processo fornecendo informações de acesso e manipulação às ferramentas que fazem parte do processo, disponibilização de metodologias para cálculos, estimativas e classificações necessárias.

Como utilizar este guia?

Este guia está dividido em seções onde uma seção atende a uma ou mais atividades inseridas no contexto daquela atividade. O acesso às seções deste guia pode ser realizado de forma direta, a partir da execução do processo por meio das atividades que necessitam e referenciam este guia, como pode ser independente da execução do processo, com livre consulta ao guia.

A navegação por este guia é facilitada pelo Sumário.

Quando utilizar este guia?

Sempre que houver necessidade, este guia deve ser consultado. As informações aqui contidas são fundamentais para a execução de certas atividades do processo, logo, fica evidente a importância deste guia no auxílio à execução. Os executantes do processo que já se sentirem familizarizados e institucionalizados com as definições deste guia, poderão abdicar-se das consultas.

Quem deve utilizar este guia?

Todos os executantes do processo (responsáveis e participantes das atividades do processo), que, de acordo com cada atividade, necessitam recorrer ao guia para consulta.


Alocação de Recursos

Atividades associadas: Definir Plano de Projeto

Os recursos humanos, recursos materiais e o ambiente de trabalho são previstos e alocados no Plano de Projeto, de acordo com as subeseções abaixo.

Recursos Humanos

Os recursos humanos alocados nos projetos devem respeitar a hierarquia da empresa para desenvolvimento de software, seguindo o relacionamento hierárquico descrito na Figura 1:


Figura 1: Organograma hierárquico padrão utilizado nos projetos da Prognus Software Livre.

A alocação dos recursos humanos para um projeto segue o organograma acima e de acordo com a Matriz de Competências da Prognus Software Livre. A Matriz de Competências contém o quadro de funcionários de produção da empresa, suas atribuições, habilidades e disponibilidade de horas.

A alocação da equipe é realizada na subseção "Matriz de Responsabilidades" do Plano de Projeto, por meio de preenchimento da matriz, identificando os integrantes da equipe e suas responsabilidades.

As descrições dos papéis e competência dos papéis descritos neste processo estão disponibilizados na seção organizacional Equipe, Papéis e Competências deste Wiki.

Integrantes ou fornecedores externos devem ser considerados na alocação dos recursos humanos e o esforço de trabalho dos mesmos deve ser estimado no Cronograma de Execução, porém deve-se considerar a existência de riscos associados a não integrantes da equipe, devendo ser identificados na atividade "Identificar Riscos e Avaliar Viabilidade" (consultar), da fase de Gerenciamento.

Recursos Materiais

Os recursos materiais necessários que forem identificados para execução de um projeto são especificados na seção "Plano Alocação de Recursos Materiais" do Plano de Projeto. Os recursos classificam-se em Ambiente de Trabalho, ou o planejamento do maquinário a ser alocado na empresa para desenvolvimento das atividades na execução do projeto; Aquisição de Equipamentos, ou a especificação de aquisição de novos equipamentos decorrentes da execução do projeto; e Outras Aquisições, ou o planejamento de aquisições específicas do projeto (viagens, locações, treinamentos, eventos).

Ambiente de Trabalho

Para execução de um projeto, o ambiente de trabalho deve ser definido e disponibilizado aos responsáveis alocados no projeto.

O ambiente de trabalho de trabalho é organizado de acordo com os perfis de cada executante alocado no projeto. A tabela abaixo relaciona cada perfil executante do projeto e suas necessidades em relação ao ambiente de trabalho:

PerfilIdentificaçãoDescrição de SoftwareDescrição de Hardware
Gerente de ProjetoAmbiente-GPSistema Operacional GNU/Linux; MrProject (Planner)Processador Intel P4 2.8GHz (ou similar), Memória RAM 1Gb, HD 80Gb
Analista de SistemasAmbiente-ASSistema Operacional GNU/Linux; MrProject (Planner); JudeProcessador Intel P4 2.8GHz (ou similar), Memória RAM 1GB, HD 120Gb
ProgramadorAmbiente-PROGEclipse IDE; VimProcessador Intel Core2Duo 1.6GHz (ou similar), Memória RAM 1GB, HD 120GB

Aquisição de Equipamentos

O planejamento da aquisição de equipamentos para o projeto é realizado pelo Gerente de Projeto, conforme as necessidades idenficadas pelo mesmo.

O planejamento ocorre na subseção "Aquisição de equipamentos" da seção "Plano Alocação de Recursos Materiais", no Plano de Projeto.

Outras Aquisições

O planejamento das aquisições materiais adicionais demandadas pelo projeto é realizado pelo Gerente de Projeto, conforme as necessidades identificadas pelo mesmo. As aquisições adicionais envolvem despesas como viagens, locação de equipamentos, treinamentos e participação em eventos.

O planejamento ocorre na subseção "Outras aquisições de recursos materiais" da seção "Plano Alocação de Recursos Materiais", no Plano de Projeto.


Banco de Demandas

Atividades associadas: Registrar Nova Demanda, Detalhar Demanda, Selecionar demandas

O Banco de Demandas do Processo de Desenvolvimento da Prognus Software Livre é a base definida para armazenar todas as demandas de desenvolvimento na empresa. O Banco de Demandas no agrupamento dos tickets registrados na Ferramenta Trac. Cada ticket possui uma página wiki associada, onde está registrado o detalhamento da DFD.

Organização do Banco de Demandas

O Banco de Demandas está definido na seção Banco de Demandas do Trac, exibindo todos os tickets e DFDs registradas.

O "Banco de Demandas" possui uma organização tal que as demandas são classificadas pelo seu milestone. Um milestone no conceito do "Banco de Demandas" é um marcador que designa a qual projeto o ticket pertence. No início de cada projeto, após a reunião de seleção das demandas, um novo milestone que corresponda à nova versão que será lançada deve ser criado. As demandas que foram selecionadas deverão ser atualizadas para pertencerem ao novo milestone do novo projeto. Para mais detalhes deste processo, consultar a subseção Registro de uma demanda.

Toda demanda que não pertecer a nenhum milestone de projeto, faz parte dos seguintes milestones: "não-planejado" e "interrompido".

Milestone "não-planejado"

As demandas listadas no milestone não-planejado são as demandas ainda não selecionadas para um projeto ou ciclo de desenvolvimento.

Milestone "interrompido"

As demandas listadas no milestone interrompido são as demandas que foram retiradas de projetos em andamento, via Processo de Mudança (consultar?), por conta de necessidades de mudança no projeto. As razões para uma demanda ser retirada de um ciclo podem ser a necessidade de implementar a demanda em outro ciclo (alta complexidade não prevista o suficiente, solicitação do cliente) ou a não viabilidade de implementação da demanda.

Registro de uma demanda

Os procedimentos para registro de uma demanda no Banco de Demandas são:

1. Criar novo Ticket (Registrar Demanda)

  • Clicar no botão "New Ticket", localizado no menu superior da ferramenta;
  • Na página de criação de um ticket, preencher os campos "Summary" (Sumário), "Description" (Descrição), "Component" (Componente), "Canal de contato", e "Requisitante", extraídos da Declaração Preliminar de Demanda;
  • Ainda na página de criação do ticket, no campo "Type" (Tipo) selecionar a opção "melhoria";
  • Marcar a opção "Backport da comunidade?", caso seja uma melhoria da Comunidade a ser inserida no projeto;
  • Ainda na página de criação do ticket, no campo "Milestone" selecionar a opção "não planejado", uma vez que a ticket referido ainda não pertence a nenhum Milestone, ou ciclo de um projeto;
  • Inserir no campo "Description" do ticket o link para a DFD que será criada, seguindo o padrao [wiki:BancoDemandas/DFDXXXX DFDXXXX]

onde, XXXX deve ser substituído pelo número identificador da demanda;

  • Clicar no botão "Create Ticket" para criar o ticket que representa o registro da demanda na Ferramenta.

É importante obsevar o número do ticket criado, pois este número identifica o mesmo e deverá ser inserido na Declaração Formal de Demanda, garantindo a relação entre o ticket registrado e a Declaração Formal de Demanda.

2. Registrar a Declaração Formal de Demanda em página wiki (Detalhar Demanda)

A página wiki do ticket registrado é a área reservada para armazenar o detalhamento da demanda. O processo de registrar uma Declaração Formal de Demanda à página wiki é realizado de forma manual, como descrito abaixo:

  • Acessar a ticket da demanda recém registrado;
  • Clicar no link "Link para a DFDXXXX", e ativar a página da nova Declaração Formal de Demanda, clicando no botão "Create this page";
  • Copiar o modelo de Declaração Formal de Demanda (acessar modelo) e colar na nova página;
  • Preencher a primeira seção da Declaração Formal de Demanda ("Definição da demanda") com as informações necessárias;
    • Dentre as informações necessárias, está a versão atual da DFD preenchida. A versão da DFD é obtida na página "History" da DFD, sendo acessada por meio do menu superior direito, clicando no botão "History".
  • Salvar a nova Declaração Formal de Demanda, clicando no botão "Submit changes".

Banco de Mudanças

Atividades associadas: Registrar necessidade de mudança, Aprovar mudança, Verificar inconsistências

O Banco de Mudanças do Processo de Desenvolvimento da Prognus Software Livre é a base definida para armazenar todas as necessidades de mudança em um projeto. O Banco de Mudanças consiste de um registro de tickets na Ferramenta Trac e uma página Wiki também da Ferramenta Trac, que agrupa as Solicitações de Mudança. Cada Solicitação de Mudança inserida na página wiki está associada a um ticket registrado.

Organização do Banco de Mudanças

A página wiki "Banco de Mudanças" incialmente encontra-se desativada, na página do ambiente inicial do projeto (acessar). O Banco de Mudanças só deve ser "ativado" caso realmente ocorram mudanças no projeto, e deve ser iniciado a partir do modelo de Página do Banco de Mudanças (acessar).

A página wiki "Banco de Mudanças" possui três seções que classificam as SM's (Solicitações de Mudança) registradas, que são: "Mudanças Concluídas", "Mudanças Não Aprovadas" e "Mudanças em Espera".

As SM's listadas em Mudanças em Espera são as que foram inseridas no Banco de Mudanças e que ainda não foram avaliadas e aprovadas.

As SM's listadas em Mudanças Concluídas são as que já foram realizadas no projeto.

As SM's listadas em Mudanças não Aprovadas são as que não foram aprovadas para serem realizadas, sendo arquivadas nesta seção do banco.

Os procedimentos de manipulação de uma mudança no Banco de Mudanças são:

1. Registrar o ticket da Solicitação de Mudança no Banco de Mudanças

Atividade Registrar necessidade de mudança

  • Clicar no botão "New Ticket", localizado no menu superior da ferramenta;
  • Na página de criação de um ticket, preencher o campo "Summary" (Sumário) seguindo o padrão:

SMXXXX - Título da Solicitação de Mudança

onde XXXX é um valor numérico que representa uma sequência de SM's;

  • Preencher no campo "Description" (Descrição) com uma rápida descrição da Solicitação de Mudança e também acrescentar à descrição o seguinte padrão de link, que apontará para a página Wiki da Solicitação de Mudança (a ser criada posteriormente):

[wiki:<versão>/BancoMudancas/SMXXXX]

O campo <versão> deve ser atualizado para o milestone referente à versão corrente do projeto em execução;

  • Selecionar a opção "mudanca" no campo "Type" (Tipo);
  • Selecionar a opção que corresponda ao milestone referente à versão corrente do projeto em execução no campo "Milestone";
  • Clicar no botão "Create Ticket" para criar o ticket que representa o registro da demanda na Ferramenta.

É importante obsevar o número do ticket criado, pois este número identifica o mesmo e deverá ser inserido na Solicitação de Mudança, garantindo a relação entre o ticket registrado e a Solicitação de Mudança.

2. Registrar a Solicitação de Mudança em página wiki

Atividade Registrar Necessidade de Mudança

A página wiki "Banco de Mudanças" é a área reservada para o registro e armazenamento das Solicitações de Mudança. O processo de adicionar uma Solicitação de Mudança à página wiki da Ferramenta é realizado de forma manual, como descrito abaixo:

  • Acessar o ticket referente à Solicitação de Mudança no "Banco de Mudanças" do projeto;
  • Ativar o link pré definido para a página wiki da Solicitação de Mudança;
  • Criar a página wiki da Solicitação de Mudança, clicando no botão "Create this page";
  • Copiar o Modelo de Solicitação de Mudança (acessar modelo) e colar na nova página;
  • Preencher a primeira seção da Declaração Formal de Demanda ("Definição da Mudança") com as informações necessárias;
  • No campo "Comment about this change (optional):" preencher com um comentário acerca da criação da página;
  • Salvar a edição da página wiki do Banco de Mudanças, clicando no botão "Submit changes";

3. Encerrar Ticket

Atividades Aprovar Mudança e Verificar Inconsistências

Seja qual for a decisão tomada em relação à mudança, o ticket associado à mudança deve ser encerrado.

Caso a mudança não for aprovada (atividade Aprovar mudança), o ticket da mudança não aprovada deve ser encerrado:

  • Clicar no botão "View Tickets", no menu superior da Ferramenta para visualizar todos os tickets existentes;
  • Acessar o ticket a ser encerrado;
  • Definir o status do ticket como encerrado, selecionando a opção "leave as closed" no final da página do ticket;
  • Selecionar a opção "naoseracorrigido" no campo "resolution"; clicar no botão "Submit changes".

Após a realização da mudança (atividade Verificar inconsistências), o ticket referente à mudança realizada deve ser encerrado:

  • Clicar no botão "View Tickets", no menu superior da Ferramenta para visualizar todos os tickets existentes;
  • Acessar o ticket a ser encerrado;
  • Definir o status do ticket como encerrado, selecionando a opção "leave as closed" no final da página do ticket;
  • Selecionar a opção "corrigido" no campo "resolution"; clicar no botão "Submit changes".

Ciclo de Vida

Atividades associadas: Definir Plano de Projeto

O Ciclo de Vida da Prognus Software Livre para projetos de desenvolvimento é apresentado nesta seção do guia. Todo projeto executado na empresa deve seguir o ciclo aqui definido.

Modelo de Desenvolvimento

O Ciclo de Vida segue o modelo de desenvolvimento em cascata, na qual o desenvolvimento segue um fluxo constante, através das fases definidas para o ciclo. Neste modelo, o progresso de uma fase ocorre somente após a conclusão da fase anterior. Ainda, de acordo com a definição, o desenvolvimento de fases no modelo em cascata são discretas, e não há pulo para frente, para trás ou sobreposição entre elas.

Fases

Os projetos que seguem o Ciclo de Vida da Prognus Software Livre devem possuir prazo de execução de pelo menos um mês, sendo suscetível a variações, conforme as demandas e necessidades de cada projeto. O ciclo está dividido em três fases, que são:

  • Gerenciamento
  • Execução
  • Lançamento

Em relação a prazos, o Ciclo de Vida é classificado em:

  • Ciclo de Vida Pequeno - Prazo de execução do projeto inferior a 6 meses.
  • Ciclo de Vida Médio - Prazo de execução do projeto igual a 6 meses.
  • Ciclo de Vida Longo - Prazo de execução do projeto superior a 6 meses.


Figura 1: Ciclo de Vida da Prognus Software Livre

Paralelo ao Ciclo de Vida, são executados os processos de Aquisição, Monitoramento e Mudança, como indicado na Figura 1. A seguir é descrito de forma sucinta as fases do ciclo de vida e os processos auxiliares.

Gerenciamento

A Fase de Gerenciamento envolve a definição do escopo do projeto (demandas selecionadas para um projeto), a análise e identificação dos riscos e o planejamento da execução do projeto.

O final desta fase representa o marco do Gerenciamento do projeto.

Execução

A Fase de Execução envolve a implementação do produto definido no escopo do projeto e está dividida em três etapas:

Especificação
Especificação das demandas a serem implementadas.
Codificação
Codificação de acordo com a especificação definida.
Teste
Teste das demandas implementadas.

O final desta fase representa o marco da Execução do projeto.

Lançamento

A Fase de Lançamento envolve a liberação e entrega do produto, seguindo as etapas:

  • Alfa;
  • Beta;
  • Release Candidate, até ser entregue a versão Final.

Em função do tempo de duração estipulado e da simplicidade de certos projetos, pode não ser viável executar estritamente as três etapas de Lançamento. Um projeto pode ser lançado a paritr apenas de uma versão RC ou Final.

O final desta fase representa o marco do Lançamento do projeto.

Aquisição

No processo de Aquisição ocorre o registro e oficialização das demandas de melhorias para o produto (Expresso Livre). Todas as demandas antes de "existirem" dentro do Ciclo de Vida, foram aquisitadas pelo processo de Aquisição.

O processo de Aquisição é externo ao Ciclo de Vida, mas deve ser aqui citado e previsto pois, independente do Ciclo de Vida, sua execução ocorre de forma constante. A execução deste processo ocorre uma vez por semana demandando um dia de esforço para tal, porém excepcionalmente podem ocorrer variações na necessidade de esforço para a aquisição, onde seja necessário esforços inferiores a um dia completo para a execução deste processo.

Monitoramento

O processo de Monitoramento ocorre ao longo do Ciclo de Vida e garante que o processo esteja alinhado com o planejamento, controlando os desvios que ocorreram em sua execução.

Mudança

O processo de Mudança está relacionado às mudanças de requisito e até mesmo de escopo que porventura vierem a acontecer durante o projeto, ao longo do Ciclo de Vida.

Esforço

A Estimativa de Esforço do Projeto é obtida com da distribuição do esforço de implementação das demandas (relacionado apenas à fase de Execução) entre as demais fases do Ciclo de Vida, seguindo a proporção definida abaixo:


Figura 2: Distribuição do esforço nas fases do Ciclo de Vida da Prognus Software Livre

Distribução do esforço(*) a ser empregado, por fase:

  • Gerenciamento: 20%()
    • Planejamento: 70%
    • Monitoramento/Identificação de Mudanças: 20%
    • Qualidade: 10%
  • Execução: 60%
    • Especificação: 40%
    • Codificação: 40%
    • Teste: 20%
  • Lançamento: 20%

(*)Definição de esforço realizada através de reunião com a alta gerência da empresa, disponível em Ata de Reunião.

()O esforço empreendido para as atividades dos processos de Monitoramento/Identificação de mudanças e Qualidade está inserido no esforço do Gerenciamento, sendo uma parcela do total reservado ao Gerenciamento.

Entregáveis

Esta seção define os produtos e marcos (Entregáveis) de cada fase ao cliente e suas respectivas formas de disponibilização.

Gerenciamento Execução Lançamento
Conjunto de DFD's Página wiki do projeto
Plano de Projeto Página wiki do projeto
Especificação das Demandas Página wiki do projeto
Código SVN do projeto (http://dev.prognus.com.br/svn-expresso/)
Versão Alfa Trac para a Comunidade
Versão Beta Trac para a Comunidade
Versão RC Trac para a Comunidade
Notas de Lançamento Trac para a Comunidade

Comunicação

Atividades associadas: Elaborar/Atualizar Plano de Projeto

Todos os documentos e dados do projeto relevantes às partes interessadas são identificados nesta seção.

As partes interessadas podem ser o Comitê Interno do Produto (Representante do Cliente, Representante da Comunidade, Gerente de Projeto) (ver definição) ou a Equipe Técnica (Analista de Sistemas, Programador, Testador) (ver definições).

A localização e as formas de acesso aos documentos e artefatos acima relacionados deve ser disponibilizado na seção "Plano de Comunicação" do Plano de Projeto.

Documento Responsável InteressadosFrequênciaLocalPermissão de acesso
Ata de Reunião de Seleção de Demandas Gerente de Projeto Comitê Interno do ProdutoAo início do projeto, na etapa de seleção de novas demandas. Fase de Gerenciamento.Trac do projeto, em todas as seções, distribuídas ao longo das fases do ciclo de vida.Comitê Interno do Produto
Matriz de Rastreabilidade Analista de SistemasGerente de ProjetoEm todas as fases do projeto, a cada necessidade de atualização da Matriz de Rastreabilidade.Trac do projeto, em todas as seções, distribuídas ao longo das fases do ciclo de vida.Gerente de Projeto
Plano de Projeto Gerente de Projeto Comitê Interno do ProdutoAo início do projeto e quando houver necessidade de alteração do documento. Fase de Gerenciamento.Trac do projeto, seção Gerenciamento.Comitê Interno do Produto
Cronograma de Execução Gerente de Projeto Comitê Interno do ProdutoAo início do projeto e quando houver necessidade de alteração do documento. Fase de Gerenciamento.Trac do projeto, seção Gerenciamento.Comitê Interno do Produto
Ata de Reunião de Viabilidade do ProjetoGerente de Projeto Comitê Interno do ProdutoAo início do projeto, na obtenção da viabilidade do projeto. Fase de Gerenciamento.Trac do projeto, seção Gerenciamento.Comitê Interno do Produto
Ata de Aprovação do Plano de Projeto Gerente de Projeto Comitê Interno do ProdutoAo início do projeto, na aprovação do planejamento do projeto. Fase de Gerenciamento.Trac do projeto, seção Gerenciamento.Comitê Interno do Produto
Especificação das DemandasAnalista de Sistemas Gerente de ProjetoInício da execução do projeto. Fase de Execução.Trac do projeto, seção Execução.Comitê Interno do Produto
Checklist de Aprovação da Especificação Gerente de Projeto Analista de SistemasApós a elaboração da Especificação das Demandas. Fase de Execução.Trac do projeto, seção Execução.Gerente de Projeto, Analista de Sistemas
Checklist de Aprovação da Codificação Analista de Sistemas Programador, Analista de SistemasApós a codificação do projeto. Fase de Execução.Trac do projeto, seção Execução.Comitê Interno do Produto
Ata de Reunião de Marco Gerente de Projeto Comitê Interno do ProdutoAo final de cada fase.Trac do projeto, em todas as seções, distribuídas ao longo das fases do ciclo de vida.Comitê Interno do Produto
Ata de Reunião de Acompanhamento Gerente de Projeto Comitê Interno do ProdutoEm todas as fases do projeto, nas reuniões de acompanhamento.Trac do projeto, seção Monitoramento.Comitê Interno do Produto

Cronograma de Execução

Atividades associadas: Definir Plano de Projeto

O template de Cronograma de Execução está disponível na página wiki Cronograma de Execução da página de modelos do processo.

No Cronograma de Execução, a dependência de execução das atividades segue a mesma sequência que se encontram listadas.


Estimativas do Projeto

Atividades associadas: Definir Prioridade da Demanda (Processo de Aquisição), Estimar Tamanho (Processo de Aquisição), Definir Plano de Projeto

Esta seção define as metodologias para priorização das demandas aquisitadas, estimativas de tamanho (tanto para demandas como para projeto) e estimativa de esforço para o projeto.

Priorização de Demandas

A priorização das demandas é realizada na atividade "Definir Prioridade da Demanda" (acessar) do Processo de Aquisição, executado fora do Processo de Desenvolvimento da Prognus Software Livre. Apesar de ser externo ao processo, a metodologia para priorização das demandas é definida nesta seção do guia.

A priorização de uma demanda aquisitada considera os seguintes critérios:

  • Avaliação da demanda por parte da Comunidade e/ou Clientes;
  • Quantidade de requisições na Comunidade e/ou Clientes para implementação da demanda.

Etapas para priorização:

1 - Classificar a demanda realizando análise sobre a mesma (sob o ponto de vista da Comunidade e/ou Clientes), de acordo com os atributos abaixo:

  • Avaliação do Cliente/Comunidade
    • Benefício esperado
    • Prejuízo causado
  • Avaliação da Empresa
    • Custo relativo
    • Risco relativo

a) Classifique o Benefício Relativo que a demanda irá proporcionar para o Cliente ou Comunidade na escala "baixa", "média" ou "alta", onde "baixa" indica benefício de pouca relevância e "alta" indica benefício de alta relevância. O julgamento deve ser feito sob o ponto de vista do usuário.

b) Classifique o “Prejuízo” Relativo que a não implementação da demanda irá causar para o Cliente ou Comunidade, utilizando a escala "baixa", "média" ou "alta", onde "baixa" indica nenhum prejuízo e "alta" grande prejuízo.

c) Obtenha a classificação da demanda de acordo com os atributos do Cliente/Comunidade:

Benefício esperado
BaixaMédiaAlta
BaixaBaixaBaixaMédia
Prejuízo causadoMédiaBaixaMédiaAlta
AltaMédiaAltaAlta

d) Estime o custo relativo da implementação da demanda utilizando a escala "baixa", "média" ou "alta", onde "baixa" representa baixo custo e "alta" representa alto custo. Este item deve ser estimado baseado na complexidade dos requisitos da demanda, a extensão do trabalho requerido para a interface do usuário, possibilidade de reutilização de código, o volume de testes e a documentação necessária.

e) Estime o grau de riscos técnicos e outros riscos associados à demanda utilizando a escala "baixa", "média" ou "alta" onde "baixa" representa baixo risco e "alta" indica alto risco.

f) Obtenha a classificação da demanda de acordo com os atributos da Empresa:

Custo relativo
BaixaMédiaAlta
BaixaBaixaBaixaMédia
Risco relativoMédiaBaixaMédiaAlta
AltaMédiaAltaAlta

g) Classifique a prioridade da demanda, a partir do cruzamento da "Classificação do Cliente/Comunidade x Classificação da Empresa":

Cliente/Comunidade
BaixaMédiaAlta
BaixaBaixaBaixaMédia
EmpresaMédiaBaixaMédiaAlta
AltaMédiaAltaAlta

2 - Classificar as demandas em função da quantidade de requisições registradas no Banco de Demandas:

ClassificaçãoQuantidade (requisições)
Baixa Quantidade < 3
Média 2 < Quantidade < 5
Alta Quantidade > 4

3 - Obter a priorização a partir do cruzamento "Avaliação da demanda pela Comunidade e Clientes X Quantidade de Requisições da Comunidade e Clientes":

Avaliação
BaixaMédiaAlta
BaixaBaixaBaixaMédia
QuantidadeMédiaBaixaMédiaAlta
AltaMédiaAltaAlta

Estimativa de Tamanho

Apresentação do método

O tamanho da demanda é obtido utilizando o método de estimativa próprio da Prognus que adota o método de Análise de Ponto de Função definido pelo IFPUG (International Function Point Users Group) e acrescenta duas alterações(*), a saber:

  • o Fator de Ajuste constante e igual a um para toda medição
  • a adição de um multiplicador (peso) para cada tipo de atividade

(*)Definição das alterações do método de Estimativa de Tamanho realizada através de reunião com a alta gerência da empresa, disponível em Ata de Reunião.

Ainda, quando for o caso, admite-se o método de Contagem Estimativa definido pela NESMA (Netherlands Software Metrics Users Association), com as mesmas duas alterações citadas.

Definição do método

O método consiste em:

  1. contar as Funções de Tipo Dado (Arquivos Lógicos Internos (ALIs) e Arquivos de Interface Externa (AIEs)) e Funções de Tipo Transação (Entradas Externas (EEs), Consultas Externas (CEs) e Saídas Externas (SEs))
  1. enquadramento de cada função (ALI, AIE, EE, SE e CE) em seu respectivo grau de complexidade, variando entre Simples, Média e Complexo, conforme as tabelas de complexidade funcional
  1. calcular a contribuição, em Pontos de Função, de cada função (ALI, AIE, EE, SE e CE) conforme a tabela de contribuição
  1. determinação do tipo de atividade para cada função (ALI, AIE, EE, SE e CE), variando entre funcionalidades adicionadas (ADD), funcionalidades alteradas (CHGA), funcionalidades de conversão de dados (CFP) e funcionalidades excluídas (DEL)
  1. atribuição do multiplicador a cada função (ALI, AIE, EE, SE e CE) de acordo com a tabela que relaciona o multiplicador (peso) com o respectivo tipo de atividade e obtenção das respectivas contribuições ajustadas com este multiplicador

O somatório das contribuições de cada item contado dá o numero de Pontos de Função da demanda.

Em todos os tipos de atividades, inclusive mudança (CHGA) e exclusão (DEL), são contados todos os Pontos de Função da funcionalidade. Assim, mesmo que, na atividade de mudança, seja possível contar os Pontos de Função adicionados pela alteração, deve-se contar o total dos pontos de função da atividade após a alteração, ou seja, os Pontos de Função existentes na funcionalidade somados aos adicionados pela alteração nesta funcionalidade, pois entende-se que uma alteração, em geral, tem grande impacto dentro de uma determinada funcionalidade.

Definição das Funções

Tipo Dado
  • Arquivos Lógicos Internos (ALI): Grupo de dados ou informações de controle logicamente relacionados, reconhecidos pelo usuário, mantidos dentro da fronteira da aplicação. Sua principal intenção é armazenar dados mantidos por um ou mais processos elementares da aplicação sendo medida.

Como exemplos de um ou mais ALIs , dependendo da visão do usuário , têm-se : (texto retirado de http://www.macoratti.net/apf_pcta.htm)

  • Dados da aplicação (arquivos mestres como cadastro de clientes ou funcionários);
  • Arquivos de dados de segurança da aplicação;
  • Arquivos de dados de auditoria;
  • Arquivos de mensagem de auxílio;
  • Arquivos de mensagens de erro;
  • Arquivo de cópia de segurança. Considerado somente se for solicitado pelo usuário para atender requisitos da aplicação.
  • Arquivo que sofra manutenção por mais de uma aplicação.

Não são considerados como ALI:

  • Arquivos temporários;
  • Arquivos de trabalho;
  • Arquivos de classificação;
  • Arquivos de cópia de segurança requerido pelo CPD.
  • Arquivos introduzidos somente por causa da tecnologia usada. Ex.: arquivos de parâmetro para um software WFL, JCL,etc.;
  • Operações de junção e projeção.
  • Arquivos de índices alternativos
  • Arquivos de Interface Externa (AIE): Grupo de dados ou informações de controle logicamente relacionados, reconhecidos pelo usuário, referenciados pela aplicação, mas mantidos dentro da fronteira de outra aplicação. Sua principal intenção é armazenar dados referenciados por um ou mais processos elementares da aplicação sendo contada. Um AIE contado para uma aplicação, deve ser um ALI em outra.

São considerados AIE , conforme a visão do usuário: (texto retirado de http://www.macoratti.net/apf_pcta.htm)

  • Dados de referência (dados externos usados pela aplicação ,mas que não são usados para manutenção em ALI);
    • Arquivos de mensagens de auxílio;
    • Arquivos de mensagens de erro.

Não são considerados AIE:

  • Dados recebidos de outra aplicação usados para adicionar, alterar ou remover dados em um ALI;
  • Dados cuja manutenção é feita pela aplicação que esta sendo avaliada mas que são acessados e utilizados por outra aplicação;
  • Dados formatados e processados para uso por outra aplicação.

Tipo Transação
  • Entradas Externas (EE): Processo elementar que processa dados ou informações de controle vindos de fora da fronteira da aplicação e cuja intenção é manter um ou mais ALIs e/ou alterar o comportamento do sistema.

São exemplos de EE (texto retirado de http://www.macoratti.net/apf_pcta.htm): Operações de inclusões e alterações de registros em arquivos da aplicação, Janela que permite adicionar, excluir e alterar registros em arquivos.

Não são exemplos de EE : Menus, Telas de Login, telas de filtro de relatórios e consultas, Múltiplos métodos de se executar uma mesma lógica de entrada

  • Saídas Externas (SE): Processo elementar cuja principal intenção é enviar dados ou informações de controle para fora da fronteira da aplicação. Sua lógica de processamento deve conter fórmula matemática ou cálculo, ou criar dados derivados, manter um ou mais ALI e/ou alterar o comportamento do sistema.

A identificação de uma saída externa pode ser feita pela identificação de todos os processos e informações de controle que enviam dados para fora da fronteira da aplicação. Satisfeita esta condição pode-se considerar uma saída externa (texto retirado de http://www.macoratti.net/apf_pcta.htm):

  • Dados transferidos para outra aplicação : dados de um ALI que são formatados (arrumados em uma ordem única) e processados para uso por uma aplicação externa.
    • Relatórios : Cada relatório produzido pela aplicação pode ser considerado uma SE. Para relatórios de formato idênticos mas que necessitam de lógicas de processamento ou cálculos distintos devem ser considerados duas saídas externas.
    • Relatórios on-line : Saída de dados on-line que não seja a parte de saída de uma consulta Externa.
    • Formatos Gráficos : Contados da mesma forma como saída em formato texto, isto é , cada formato gráfico diferente é contado como uma saída externa.
  • Gerador de relatórios : Cada relatório de uma saída desenvolvida para o usuário via gerador de relatório deve ser considerado como uma saída externa.

Não devem ser considerados como saídas externas:

  • Telas de Ajuda;
  • Literais;
  • Data, hora, controles de paginação , etc.;
  • Relatórios múltiplos com a mesma lógica e formato
  • Relatórios criados pelo usuário de forma dinâmica pelo usuário usando um linguagem como SQL.

  • Consultas Externas (CE): Processo elementar cuja principal é enviar dados ou informações de controle para fora da fronteira da aplicação pela simples recuperação de dados de ALI e/ou AIE. Sua lógica de processamento não deve conter fórmula matemática ou cálculo, nem criar dados derivados, nem manter um ou mais ALI, nem alterar o comportamento do sistema.

Pode-se citar como exemplos de CE (texto retirado de http://www.macoratti.net/apf_pcta.htm):

  • Um processo de recuperação de dados que seleciona dados com base em uma entrada fornecida;
  • Telas de Logon;
  • Telas de Help;
  • Telas de alteração/remoção que mostram o que será alterado ou removido antes de sua efetivação.
  • Tela de menus que permitem informar parâmetros para a consulta na tela escolhida.

Não são consideras CE:

  • Telas de Menus que oferecem somente funcionalidade de seleção de telas;
  • Dados derivados;
  • Documentação On-Line;
  • Sistema de Teste;
  • Sistema Tutoriais;
  • Relatórios e consultas que contenham cálculo ou gerem dados derivados.

Tabelas de referência


Figura 3: Tabela de Complexidade Funcional dos ALI e AIE.


Figura 4: Tabela de Complexidade Funcional das EE.


Figura 5: Tabela de Complexidade Funcional das SE e CE. Cada CE deve referenciar ao menos 1 ALI ou AIE


Figura 6: Tabela de Contribuição Funcional.


Figura 7: Tabela de Pesos das atividades.

Preenchimento do template

No template, a manipulação das tabelas no arquivo envolve apenas o preenchimento da quantidade das funções (ALIs, AIEs, EEs, CEs ou SEs) e seu respectivo grau de complexidade. O cálculo da contribuição de cada função e somatório das contribuições é gerado automaticamente.

Para preenchimento das planilhas de estimativa de tamanho da demanda, o analista, com a Descrição Formal de Demanda (DFD) em mãos, deve obter o número de ALIs, AIEs, EEs, CEs e SEs de cada requisito descrito na DFD e deve preencher a tabela “Contagem das Funcionalidades” na planilha “PFs não Ajustados”, onde as colunas representam:

  • Referência do requisito: Requisito de onde provêm a função, conforme descrição dada pela DFD
  • Tipo: Tipo de atividade para a função (ADD, CHGA, CFP, DEL)
  • Função: Tipo da função
  • Classificação: classificação da função conforme grau de complexidade, podendo assumir os valores S (Simples), M (Média) ou C (Complexa)
  • Quantidade: quantidade de funções com as características dadas
  • Nº. de PF: número de Pontos de Função, calculado automaticamente, resultado do somatório das contribuições multiplicadas pelo peso dado pelo tipo de atividade

O analista deve atentar-se para a existência de duas tabelas de “Contagem das Funcionalidades”: uma para as funcionalidades com tipo DEL de atividade e outra para os demais tipos de atividades (ADD, CHGA, CFP).

Tamanho do Projeto

O conceito Tamanho do Projeto aqui referido envolve apenas o tamanho total das demandas selecionadas para um projeto. O tamanho total das demandas para o projeto é obtido com a simples soma das estimativas de tamanho de cada DFD que foi selecionada para o projeto.

Estimativa de Esforço

O esforço necessário para executar o projeto parte da Estimativa de Tamanho das demandas selecionadas (consultar seção anterior).

Abaixo seguem as relações de produtividade considerando a produtividade da empresa em um dado momento:

Valor hora/PF: 7,48h/PF (produtividade atual, após cálculo realizado e embasado no ticket #41)

Valor hora/PF: 8h/PF (alta produtividade)

Valor hora/PF: 10h/PF (média produtividade)

Valor hora/PF: 12h/PF (baixa produtividade)

A Estimativa de Esforço do Projeto é obtida diretamente da Estimativa de Tamanho do Projeto, sendo a relação entre a produtividade (hora/PF) da empresa e a estimativa de tamanho obtida (PF):

EP = (ET * P)

Na produtividade da empresa são considerados alguns fatores que influenciam no seu valor. Dentre os fatores, encontra-se a sobrecarga de execução deste processo. De acordo com a distribuição de esforço apresentada na seção "Ciclo de Vida" deste guia (consultar), 20% do Esforço do Projeto é destinado à Fase de Gerenciamento e 20% à Fase de Lançamento. O esforço para estas duas fases do Ciclo de Vida já é considerado no valor da produtividade, ou seja, não deve ser considerado para o cálculo da Estimativa de Esforço do Projeto.

Legenda:

  • P = Produtividade
  • ET = Estimativa de Tamanho do Projeto
  • EP = Esforço do Projeto

Estimativa de Custo

O cálculo para a obtenção da estimativa de custo é a simples relação entre a estimativa de esforço (em horas) obtida e o valor da hora da empresa:

EC = (Valor da hora x EP)

(*)Valor definido na Planilha de Orçamento da Empresa, disponível apenas à alta gerência.

Legenda:

  • EC = Estimativa de Custo

Itens de Ação

Atividades associadas: Selcionar Demandas, Encaminhar Itens de Ação, Verificar aderência, Corrigir inconsistências (Processo de Aquisição e Qualidade)

No Processo de Desenvolvimento da Prognus Software Livre, os Itens de Ação descritos nas atividades "Selecionar Demandas", "Encaminhar Itens de Ação", "Verificar aderência" e "Corrigir inconsistências" são implementados pela Ferramenta Trac como tickets de tarefas.

Os itens de ação representam ações ou atividades específicas para resolver as não conformidades detectadas nos marcos e pontos de acompanhamento do projeto. Para cada Item de Ação identificado, deve ser aberto um ticket na Ferramenta Trac.

A manipulação dos tickets envolve os procedimentos de abertura e encerramento dos mesmos. Após aberto, o ticket permanecerá aberto enquanto nao houver a resolução do item de ação. Uma vez resolvido, o ticket relacionado ao item de ação deve ser encerrado.

Abertura de Tickets

Para abertura de um ticket, deve ser seguido este procedimento:

  • Clicar no botão "New Ticket", localizado no menu superior da ferramenta;
  • Na página de criação do ticket, preencher os campos "Título", "Total de Horas", "Requisitante" e "Responsável";
  • A caixa de seleção "Tipo" deve ser marcada como "Item de Ação";
  • Clicar no botão "Create Ticket" para criar o ticket que representa o registro da demanda na Ferramenta.

O campo "Descrição" deve explicar sucintamente o motivo da criação do item de ação, listando as não conformidades detectadas que demandaram a criação do mesmo. A descrição também deve referenciar um link para a Ata de Reunião ou Checklist que gerou o item de ação, para eventuais consultas por parte do responsável ou responsáveis pelo item de ação e também deve haver a previsão para resolução do item de ação.

Aceite

O responsável pela resolução do item de ação deve receber uma notificação via e-mail de que o ticket foi aberto e que ele é o responsável pelo mesmo. O aceite ao ticket ocorre quando o responsável acessa a página do ticket (link do ticket recebido na notificação via e-mail) na ferramenta e clica no botão "Accept".

Realização das atividades

O responsável pelo item de ação (ticket) deve inicializar o mesmo a cada instante que for trabalhar na execução das atividades propostas, para que haja um monitoramento das horas de execução do item de ação.

Abaixo segue o procedimento para a inicialização de um ticket:

  • Identificar o ticket que será resolvido, na seção "Atividades que preciso dar encaminhamento" da página inicial do Trac;
  • Acessar o ticket;
  • Clicar no botão "Start work";

Após este procedimento, o reponsável pelo item de ação deve executar as atividades de resolução normalmente. Comentários e observações devem ser inseridas ao final do ticket, de modo que seja possível realizar o acompanhamento da resolução das atividades. Cada vez que forem interrompidas as atividades, o responsável pelo item de ação deve clicar no botão "Stop work".

Encerramento de Tickets

O encerramento dos itens de ação é realizado em função das horas de execução estimadas para resolução do ticket. O requisitante deve verificar com o responsável pelo item de ação se a resolução do item de ação está finalizada no momento em que o ticket atingir o número de horas estabelecidas para sua resolução.

Após a resolução do item de ação, o requisitante deve setar o status do ticket para resolvido, selecionando a opção "leave as solved", ao final da página do ticket, e clicar no botão "Submit changes".


Processo de Aquisição

Ticket de Aquisição de Demanas

Detalhes do ticket de aquisição a ser criado (seguir este padrão) pelo Responsável pelo Processo de Aquisição:

  • Campo "Summary" (Título) - O título deve seguir o padrão: "AQUXXXX - DFDYYYY, DFDZZZZ", onde XXXX deve representar uma sequência numérica que identifique o ticket.
  • Campo "Description" (Descrição)
    DFDYYYY {link para o ticket da DFD}
    DFDZZZZ {link para o ticket da DFD}
    
  • Campo "Type" (Tipo) - Deve ser marcado como "Tarefa"
  • Campo "Milestone" - Deve ser selecionado a opção "aquisicao"
  • Campo "Estimated Hours" (Horas estimadas) - Deve ser preenchido as horas estimadas para a aquisição das demandas
  • Campo "Assign to" (Atribuir a) - Identificação do Analista responsável pelo detalhamento e estimativa de tamanho
  • Campo "Revisor" - Identificação do Analista responsável pela revisão da demanda

Após preencher os campos acima, clicar no botão "Creat ticket" (Criar ticket).

O analista responsável pelo ticket (o mesmo que é responsável pela detalhamento e estimativa de tamanho da demanda) será notificado automaticamente da criação do mesmo. O analista responsável pela revisão da demana (especificado no campo "Revisor") deve ser notificado pelo Responsável pelo Processo de Aquisição.

O ticket deve ser "startado" a cada momento em que os interessados no Processo de Aquisição forem executar as atividades do processo, clicando no botão "Start work", no ticket. Após a execução das atividades, o ticket deve ser interrompido, clicando no botão "Stop work".

Ticket de Monitoramento da Aquisição

Detalhes do ticket de monitoramento a ser criado (seguir este padrão) pelo Responsável pelo Processo de Aquisição:

  • Campo "Summary" (Título) - O título deve seguir o padrão: "Monitoramento - AQUXXXX, AQUYYYY", onde AQUXXXX e AQUYYY são Tickets de Aquisição de Demandas que estão atrelados a este ticket.
  • Campo "Description" (Descrição) - Breve descrição referente ao monitoramento dos tickets de aquisição AQUXXXX, AQUYYYY
  • Campo "Type" (Tipo) - Deve ser marcado como "Tarefa"
  • Campo "Milestone" - Deve ser selecionado a opção "aquisicao"
  • Campo "Estimated Hours" (Horas estimadas) - Deve ser preenchido 8 horas
  • Campo "Assign to" (Atribuir a) - Identificação do Responsável pelo Processo de Aquisição (o próprio registrante deste ticket)

Após preencher os campos acima, clicar no botão "Creat ticket" (Criar ticket).

O ticket deve ser "startado" a cada momento em que o Responsável pelo Processo de Aquisição acompanhar as atividades do processo, clicando no botão "Start work", no ticket. Após a o monitoramento do processo, o ticket deve ser interrompido, clicando no botão "Stop work".


Rastreabilidade

Atividades associadas: Definir e Manter Matriz de Rastreabilidade, Atualizar Matriz de Rastreabilidade

A fim de estabelecer a rastreabilidade nos projetos executados na Prognus Software Livre, a estratégia de rastreabilidade consiste no relacionamento entre os documentos Declaração Formal de Demanda, Plano de Projeto e Especificação das Demandas.

Esta estratégia é implementada e garantida por duas abordagens aqui descritas. A primeira estabelece que os artefatos possuam links entre si, possibilitando avançar ou retroceder nos documentos que são produzidos ao longo das fases do processo de desenvolvimento. A segunda abordagem é uma concentração de todos os links de rastreabilidade em uma tabela, listando as Declarações Formal de Demanda, cada Requisito Funcional da Declaração Formal de Demanda e os artefatos da Especificação das Demandas (Casos de Uso, Especificação da Arquitetura e Especificação do Arquivo Fonte da codificação). Esta tabela forma a Matriz de Rastreabilidade do projeto (horizontal e vertical).

Links de rastreabilidade

Ao final dos documentos Declaração Formal de Demanda, Plano de Projeto e Especificação das Demandas estão localizadas as seções "Rastreabilidade". Em cada seção destes documentos, existem determinados links que devem ser preenchidos ou atualizados ao longo do processo. Estes links permitem a rastreabilidade entre os documentos do projeto, e estabelece uma ligação entre todos os documentos gerados, formando os links de rastreabilidade do projeto.

A rastreabilidade horizontal (consultar terminologia?) ocorre entre DFD's, onde cada DFD relaciona, por meio dos links de rastreabilidade, as DFD's que serão afetadas pela mesma. Além das DFD's, os requisitos funcionais de cada DFD's também são relacionados entre si na Matriz de Rastreabilidade.

A rastreabilidade vertical (consultar terminologia?) ocorre entre os documentos gerados em cada fase, sendo: Declaração Formal de Demanda e Plano de Projeto (Gerenciamento), Especificação das Demandas (Execução).

Para cada atividade do processo, abaixo segue a relação e procedimento para inserção dos links de rastreabilidade (horizontal e vertical) nos respectivos documentos:

Definir e Manter Matriz de Rastreabilidade (Fase de Gerenciamento)

Documento [Declaração Formal de Demanda]

  • Link [Conjunto de demandas selecionadas]: Listar os links das outras DFDs selecionadas para o projeto que são afetadas pela DFD em questão. Exemplo de situação onde existe tal necessidade: Requisito Funcional de outra DFD afeta Requisito Funcional da DFD em questão.

Caso nenhuma DFD seja afetada, descrever que a DFD em questão não afeta ou não é afetada por outra DFD selecionada para o projeto: "Nenhuma demanda selecionada para o projeto é afetada por esta."

Atualizar Matriz de Rastreabilidade (Fase de Execução)

Documento [Declaração Formal de Demanda]

  • Link [Plano de Projeto]: Deve ser inserido o link para o documento Plano de Projeto.
  • Link [Especificação das demandas]: Deve ser inserido o link para o documento Especificação das Demandas.

Documento [Plano de Projeto]

  • Link [Conjunto de demandas selecionadas]: Deve ser inserido o link para a página do projeto que lista as demandas selecionadas (DFD's).
  • Link [Especificação das demandas]: Deve ser inserido o link para o documento Especificação das Demandas.

Documento [Especificação das Demandas]

  • Link [Conjunto de demandas selecionadas]: Deve ser inserido o link para a página do projeto que lista as demandas selecionadas (DFD's).
  • Link [Plano de Projeto]: Deve ser inserido o link para o documento Plano de Projeto.

Atualizar Matriz de Rastreabilidade (Processo de Mudança)

  • Atualizar todos os links de todos os documentos produzidos até o momento, conforme a necessidade que foi gerada pela mudança.

Estrutura da Matriz de Rastreabilidade

Em paralelo com os links de rastreabilidade, existe a Matriz de Rastreabilidade, formada pela tabela proposta no modelo de Matriz de Rastreabilidade (modelo?).

Abaixo encontra-se uma tabela modelo:

Tabela 1: Rastreabilidade de artefatos

ArtefatoDeclaração Formal de DemandaEspecificação das DemandasArquitetura (Espc. das Demandas)Arquivo Fonte (Espc. das Demandas)Revisão
Requisitos
<RF01><link para a DFD01><link para a espec. do DFD01><camanda relacionada na arquitetura><arquivo criado ou afetado><número da revisão do commit no código>
<RF02><link para a DFD01><link para a espec. do DFD02><camanda relacionada na arquitetura><arquivo criado ou afetado><número da revisão do commit no código>
<RF01><link para a DFD02><link para a espec. do DFD03><camanda relacionada na arquitetura><arquivo criado ou afetado><número da revisão do commit no código>
<RF02><link para a DFD02><link para a espec. do DFD04><camanda relacionada na arquitetura><arquivo criado ou afetado><número da revisão do commit no código>
<...><...><...><...><...><...>
<...><...><...><...><...><...>

Tabela 2: Rastreabilidade de Requisitos Funcionais

<RFXX><RFYY><...><...>
<RFXX>----
<RFYY>----
<...>---
<...>---

Tabela 3: Responsáveis

<DFDXX><Nome(s)>
<DFDYY><Nome(s)>

Instruções para preenchimento da tabela, por atividade:

Atividade [Definir e Manter Matriz de Rastreabilidade] (Fase de Planejamento)

Nesta atividade a Matriz de Rastreabilidade deve ser criada a partir do template da Matriz de Rastreabilidade (modelo).

  • A Tabela 1 (Rastreabilidade de Artefatos) é mantida em função dos Requisitos Funcionais das demandas, portanto, é necessário listar, na primeira coluna da tabela, todos os Requisitos Funcionais de todas as Declarações Formal de Demanda que foram selecionadas para o projeto.
  • Na segunda coluna da Tabela 1, devem ser listados os links das Declarações Formal de Demanda associadas à cada Requisito Funcional da primeira coluna da tabela.
  • Na Tabela 2 (Rastreabilidade de Requisitos Funcionais) devem ser identificadas as relações entre os Requisitos Funcionais das demandas selecionadas. Para identificar, é necessário assinalar com um "X" a célula da tabela na qual indique o "cruzamento" entre requisitos que afetam entre si.
  • Na Tabela 3 (Responsáveis) devem ser identificados os responsáveis pela manutenção da Matriz de Rastreabilidade de cada DFD do projeto.

Estas devem ser as únicas alterações necessárias na matriz por enquanto.

Atividade [Atualizar Matriz de Rastreabilidade] (Fase de Execução)

Nesta atividade ocorre a atualização da Matriz de Rastreabilidade, completando os itens da matriz.

  • Na Tabela 1, na coluna "Especificação das Demandas", devem ser listados os links que referenciam a especificação de cada DFD associada.
  • Na Tabela 1, na coluna "Arquitetura (Espc. das Demandas)", devem ser listadas as respectivas camadas da arquitetura do Expresso Livre que cada Requisito Funcional irá afetar. As camadas estão especificadas no documento Especificação das Demandas.
  • Na Tabela 1, na coluna "Arquivo Fonte (Espc. das Demandas)", devem ser listados os respecitivos nomes de arquivo/classe que irão ser afetados por cada Requisito Funcional. Os arquivos estão relacionados no documento Especificação das Demandas.

Estas devem ser as únicas alterações necessárias na matriz por enquanto.

Atividade [Aprovar Codificação das Demandas] (Fase de Execução)

Na aprovação da codificação das demandas, deve haver uma última atualização na Tabela 1. Devem ser listados os números de revisão do commit realizado código. A numeração segue um dos padrões estabelecidos na documentação TracLinks, sendo X, onde X representa o número correspondente à revisão do código do projeto, listada em http://trac.expressolivre.org/browser.

Após as inserções destes itens na Matriz de Rastreabilidade, ela está concluída, devendo apenas ser atualizada quando houverem alterações no projeto. Para tal, a atividade Atualizar Matriz de Rastreabilidade do Processo de Mudança irá se preocupar em mantê-la consistente e atualizada.

Atividade [Atualizar Matriz de Rastreabilidade] (Processo de Mudança)

No Processo de Mudança, a atividade Atualizar Matriz de Rastreabilidade é responsável por atualizar a matriz após as mudanças realizadas no projeto.

O Analista de Sistemas, executante da atividade, deve atualizar todos os nomes de documento, e links listados na matriz.


Riscos e Viabilidade

Atividades associadas: Elaborar/Atualizar Plano de Projeto

Os riscos obtidos são classificados de acordo com critérios definidos para impacto e probabilidade dos riscos. As tabelas 1 e 2 abaixo contêm, respectivamente, os critérios para definir o impacto de um risco e a probabilidade de um risco.

Tabela 1: Critérios para definir o impacto de um risco

Muito baixoBaixoModeradoAltoMuito alto
CustoAumento insignificanteMenos de 5% de aumentoAumento entre 5% e 10%Aumento entre 10% e 20%Aumento maior que 20%
PrazoDesvio insignificanteMenos de 5% de atrasoAtraso entre 5% e 10%Atraso entre 10% e 20%Atraso maior que 20%
EscopoVariação imperceptívelVariação pequenaVariação grandeVariação inaceitável para clienteProjeto fica inviável

Tabela 2: Critérios para definir a probabilidade de um risco

PontuaçãoProbabilidade percebidaProbabilidade percentual
Muito BaixoAs chances são insignificantes; É muito provável; Não há praticamente chance nenhumaMenos que 20%
BaixoPouca chance; Provavelmente não acontecerá; ImprovávelMenos que 40%
ModeradoPouco provável; Existem dúvidas; Mais ou menosMenos que 60%
AltoProvavelmente; PresumívelMenos que 80%
Muito altoAs chances são consideráveis; Muito provável; É praticamente certoMenos que 100%

Tabela 3: Classificação do risco

Impacto
Muito baixoBaixoModeradoAltoMuito alto
12345
Muito alto556789
Alto445678
ProbabilidadeModerado334567
Baixo223456
Muito baixo112345

Passos para classificação de cada risco:

  • Classificar o impacto do risco, de acordo com os critérios da Tabela 1;
  • Classificar a probabilidade de ocorrência do risco, de acordo com os critérios da Tabela 2;
  • Obter a classificação do risco na Tabela 3, a partir da combinação do impacto e da probabilidade obtidos nas Tabelas 1 e 2 respectivamente.

Tabela 4: Prioridade de tratamento do risco

Cada risco já classificado, deve ser priorizado. A priorizadação de um risco esta relacionada à classificação obtida para o risco.

ClassificaçãoPrioridade
9Alta
8Alta
7Alta
6Média
5Média
4Média
3Baixa
2Baixa
1Baixa

Seleção de Demandas

Atividades associadas: Selecionar Demandas

As demandas registradas no Banco de Demandas são passíveis de serem selecionadas para compor um projeto. No Fase de Planejamento, a atividade Selecionar Demandas se preocupa em garantir esta seleção. Esta seção do guia explicita os procedimentos necessários para o acesso às demandas e seleção das mesmas.

Acesso ao Banco de Demandas

O Banco de Demandas é acessado por meio do endereço /BancoDemandas?, a partir do link raíz do Trac, por exemplo, https://dev.prognus.com.br/BancoDemandas.

Análise e seleção

O Banco de Demandas (acessar) está organizado por tipos de demandas, classificadas pelos seus milestones: "não-planejado" e "interrompido", conforme definido em Organização do Banco de Demandas (acessar), na seção Banco de Demandas deste guia.

Primeiramente são analisadas as demandas listadas em "interrompido" e, em seguida, são analisadas as demandas listadas em "não-planejado". Abaixo segue a ordem e os conceitos para as análises:

Ordem de análise

  • 1°: Analisar as demandas listadas no milestone "interrompido"
    • As demandas interrompidas são originadas de mudanças ocorridas em projetos já executados, e devem ser revistas já na primeira oportunidade de seleção de demandas. As razões para uma demanda ter sido "descartada" de um projeto pode ser a necessidade de implementá-la em outro ciclo (alta complexidade não prevista o suficiente no planejamento, solicitação do cliente) ou a não viabilidade de implementação da mesma.
    • Caso uma Declaração Formal de Demanda (demanda) foi considerada inviável, as possibilidades de uma nova seleção tornam-se mínimas, cabendo ao Comitê Interno do Produto decidir se a demanda deve ser analisada ou se a inviabilidade da mesma é mantida, ignorando-a no processo de seleção.
    • Se uma Declaração Formal de Demanda analisada foi retirada do projeto pelos outros motivos que não sejam inviabilidade de implementação, a análise deve considerar além da Estimativa de Tamanho e prioridade da demanda, os motivos de retirada do projeto, a documentação produzida da demanda e o que foi implementado até o momento na demanda, verificando a possibilidade de selecioná-la novamente em um projeto.
  • 2°: Analisar as demandas listadas no milestone "não-planejado"
    • As DFD's categorizadas em "não-planejado" representam demandas nunca antes implentadas. Para selecioná-las, segue a prioridade de seleção de cada demanda, considerando o tamanho do ciclo de vida:
      • Necessidade de execução de um projeto com Ciclo de Vida Pequeno: Estimativa de Tamanho da demanda >> Prioridade da demanda;
      • Necessidade de execução de um projeto em um Ciclo de Vida Médio: Estimativa de Tamanho da demanda >> Prioridade da demanda;
      • Necessidade de execução de um projeto em um Ciclo de Vida Longo: Prioridade da demanda >> Estimativa de Tamanho da Demanda.

Attachments