Árvore de páginas

Atualização Necessária

Todo o conteúdo deste espaço carece de atualização e, embora tenha validade nas suas intenções, as informações existentes podem ter divergências quanto à realidade atualizada, pois tratam-se de materiais bastante antigos (alguns com mais de 5 anos de existência) e que sofreram adaptações e evoluções ao longo dos anos, sem terem sido atualizados aqui.
Assim, pede-se ao leitor evitar de tomar decisões com base apenas no material aqui existente.

Skip to end of metadata
Go to start of metadata

Aqui voce encontra

Os estereótipos de features que podem existir no 3PUP.

Conteúdo:

1. Definição

Toda feature (vide Tipo Feature) possui uma característica em especial que lhe permite categorizá-la em um grupo muito específico de utilidade. Esta utilidade determina a sua função de valor no sistema, ou seja, para qual propósito ela existe. Isso é chamado de Esterótipo.

O estereótipo da feature determina a sua função, a sua valência, a sua categoria. Ela permite extrair relatórios gerenciais muito importantes e, em especial, comparar projetos e sistemas entre si, bem como quantificar este ou aquele sistema em relação ao que ele custa ou o que ele entrega para o cliente final.

Algumas perguntas que podem ser feitas geralmente em um projeto são:

  • Quanto do esforço deste projeto foi dedicado (ou está ou será) prático para o cliente final?
  • Quanto do sistema está sendo dedicado para esforço gerencial ou horas internas de arquitetura ou refagoração, ou de melhorias imperceptíveis para o cliente final?
  • Quando de tempo está sendo gasto em correções, ou falhas ou problemas relacionados a riscos ou imprevistos?

Estas e inúmeras outras perguntas são parte natural de todo o esforço gerencial de um projeto. E cada metodologia pode utilizar regras ou mesmo, deixar que o gerente do projeto ou a equipe faça invenções para controlar isso.

Os estereótipos das features são os elementos propositalmente desenhados para estas respostas.

Assim, cada feature pode ser enquadrada em um esterótipo e, com isso, ao longo do desdobramennto do escopo e progresso do projeto, essas respostas são consquências naturais de um projeto 3PUP.

Os esterótipos de features foram concebitos para ser um arcabouço, o alicerce fundamental para estas respostas, e elas são elecados abaixo:

1.1. Esterótipos de Features

Os esterótipos possíveis para uma feature são:

1.1.1.  User Feature

Ícone sugerido:

Representa uma característica ou função de alto de valor agregado para o cliente que é executada pelo diretamente pelo próprio usuário final do sistema. É algo que o usuário diretamente está envolvido, seja acionando a feature ou recebendo diretamente o resultado da feature.

Exemplos são:

  • O pressionamento de um botão.
  • Uma mensagem de alerta que é exigida para ele.
  • Um papel que sai impresso em uma impressora.
  • Um email que ele recebe.
  • O movimento de um drag-and-drop que ele realiza.
  • Um som que ele ouve no alto-falante do computador.

Toda e qualquer feature que tenha o envolvimento direto do usuário final é uma User Feature.

1.1.2. Developer Feature

Ícone sugerido:

Atividade desempenhada por membro da equipe do projeto, que visa agregar valor ao projeto durante a sua execucao, e nao apos a sua conclusão, tais como mentoria, consultoria, treinamento, instalações, etc.

Em outras palavras, uma Developer Feature engloba todas foisas feitas internamente pela equipe, que prepara o ambiente, configura, pesquisa ou implementa algo para que depois o valor seja entregue: então ela é uma Developer Feature.

1.1.3. Aquisition Feature

Ícone sugerido:

Semelhante à Developer Feature, é uma atividade de aquisição de recursos para o projeto desempenhada por membro da equipe, e que visa agregar valor ao projeto durante ou após sua conclusão. Esse tipo de feature existe para satisfazer o Processo de Aquisições, descrito pelo MPS.br.

1.1.4. System Feature

Ícone sugerido:

Uma função ou característica que deve ser suportada e executada pelo próprio sistema final, sem participação de um usuário, tais como processos de integracao automatizados. Também contempla as "habilidades" (requisitos nao funcionais) do sistema.

1.1.5. Overload Feature

Ícone sugerido:

Tarefa desempenhada por membro da equipe do projeto que nao eh percebida diretamente pelo cliente final, mas que eh essencial para a conducao do projeto, tais como gerenciamento, infraestrutura, suporte tecnologico, pesquisas, reunioes de equipe, etc. Para mais detalhes, veja item relacionado "Overload Task" em http://xprocess.blogspot.com/2009/05/what-is-overhead-task.html

1.1.6. Risk Feature

Ícone sugerido:

Qualquer condição mapeada, ou seja, prevista, que, se ocorrer, pode afetar o projeto de alguma forma, negativa ou positivamente. Os riscos são calculados utilizando abordagem do PMBOK, onde a sua prioridade é o equivalente a multiplicação dos Feature Points (FEP) versus a probabilidade da sua ocorrência. É o inverso do happen.

1.1.7. Happen Feature

Ícone sugerido:

Qualquer evento não mapeado, ou seja, imprevisto, que atue de forma negativa ou positivamente para o projeto, comprometendo ou melhorando seu desempenho. É o inverso do risco.

1.1.8.  Fail Feature

Ícone sugerido:

Atividades que representam defeitos detectados antes da entrega da feature. São os únicos sub-tipos dentro do processo 3PUP, e podem existir ou serem criados em qualquer momento (status) de uma feature não finalizada (entregue) ainda. A existência de falhas não finalizadas, implica que a feature não pode ser finalizada também.

1.2. Exemplos de Uso de Esterótipos em Features

A tabela abaixo traz uma relação de exemplos de uso de esterótipos para organização de features seguindo o Padrão AARON:

Tipo

ATOR

AÇÃO

artigo

RESULTADO

preposição

OBJETO DE DOMÍNIO

preposição

OBJETIVO DE NEGÓCIO

Operador de terminal

imprimir

o

espelho

da

nota fiscal eletrônica

para

permitir liberação do transporte

Administrador

listar

os

usuários ativos

do

sistema

para

verificar quem está contando como licenciamento

Cliente

adicionar

o

item de compra

ao

carrinho de compras

para

avançar na sua compra

Administrador

criar

o

modelo arquitetural

do

sistema

para

para nortear estrutura-base de desenvolvimento.

Equipe

realizar

a

reunião de lançamento

do

projeto

para

comunicar o plano de projeto a todos

Gerente

gerenciar

as

atividades

do

projeto

para

manter cronograma de trabalho do projeto