PERT/CPM | |
---|---|
Program Evaluation and Review Technique ou PERT é usado em planejamento. As técnicas denominadas PERT e CPM foram independentemente desenvolvidas para o Planejamento e Controle de Projetos em torno de 1950, porém a grande semelhança entre estas fez com que o termo PERT/CPM fosse utilizado corriqueiramente como apenas uma técnica. Os termos PERT e CPM são acrônimos de Program Evaluation and Review Technique (PERT) e Critical Path Method (CPM). Exemplos de Projetos que podem utilizar PERT/CPM: 1. Construção de uma planta 2. Pesquisa e desenvolvimento de um produto 3. Produção de filmes 4. Construção de navios 5. Instalação de um sistema de informações 6. Condução de campanhas publicitárias, entre outras. PERT e CPM utilizam principalmente os conceitos de Redes (Grafos) para planejar e visualizar a coordenação das atividades do projeto. Enquanto PERT é o cálculo a partir da média ponderada de 3 durações possíveis de uma atividade (otimista, mais provável e pessimista), CPM é um método de apuração do caminho crítico dada uma sequência de atividades, isto é, quais atividades de uma sequência não podem sofrer alteração de duração sem que isso reflita na duração total de um projeto. Um exemplo clássico de aplicação de PERT/CPM é o planejamento e gerenciamento da construção civil.. | |
PMBOK | |
---|---|
O "Project Management Body of Knowledge" (PMBOK® Guide) é um termo que abrange o universo do conhecimento da profissão de Gerenciamento de Projetos. Ele descreve o subconjunto do universo do conhecimento de Gerenciamento de Projetos reconhecido como boas práticas em muitos projetos na maior parte do tempo, havendo consenso pelos praticantes sobre seus valores e aplicabilidade. Entretanto, a aceitação geral não representa a necessidade de aplicação uniforme em todos os projetos, devendo ser definido o que é apropriado para cada projeto / indústria. Ele também estabelece uma linguagem comum para a profissão de gerente de projetos. | |
Ponto de Função | |
---|---|
É a unidade de medida da APF que representa o tamanho funcional de um software. | |
Ponto de Função de Teste | |
---|---|
Unidade de medida do tamanho das funções sujeitas a teste. Conceito empregado pela NESMA no seu método de medição do projeto de melhoria. | |
Preço Global Fixo | |
---|---|
Essa modalidade de contratação privilegia a abordagem de projeto, com um início e fim bem definidos. Exige maior nível de organização tanto por parte do cliente quanto do fornecedor. Quanto melhor estiverem os requisitos, menor a chance de atritos entre ambos. Um fator que complica a utilização desta abordagem é assumir que os requisitos não mudam após o início do projeto. | |
Preço Unitário | |
---|---|
Nesse modelo, é definida uma remuneração para o fornecedor sobre os elementos do projeto. Esse elemento pode assumir várias formas: tela, relatório, tabela, caso de uso, linha de código ou ponto de função. Em tese é um modelo que procura equilibrar as deficiências da contratação por homem hora e por preço global fixo. | |
Processamento Distribuído | |
---|---|
Uma das 14 características gerais de sistema que descreve o grau pelo qual a aplicação transfere dados entre seus componentes. Pontue de acordo com as seguintes orientações: | |
Processo Elementar | |
---|---|
É a menor unidade de atividade significativa para o usuário, completa e que deixa o negócio da aplicação em um estado consistente. Pode ser classificado em entrada externa (EE), saída externa (SE) e consulta externa (CE). Também chamado de transação. Para que um processo elementar seja único, ou seja, diferente de qualquer outro, ao menos um dos três itens abaixo deve ser ocorrer: - conjunto de tipos de dados diferentes de outra transação; - conjunto de arquivos referenciados diferentes de outra transação; - lógica de processamento diferente de outra transação | |
Processo Unificado | |
---|---|
O processo unificado (UP) de desenvolvimento de software é o conjunto de atividades necessárias para transformar requisitos do usuário em um sistema de software. O UP de desenvolvimento de sistemas combina os ciclos iterativo e incremental para a construção de softwares. É fundamental na visão de que o avanço de um projeto deve estar baseado na construção de artefatos de software, e não apenas em documentação. | |
Produtividade | |
---|---|
É basicamente definida como a relação entre a produção e os insumos utilizados. No contexto de desenvolvimento de software, pode ser expressa na unidade PF/Homem-mês | |
Project Management Institute | |
---|---|
O Project Management Institute (PMI) é a principal associação mundial de gerenciamento de projetos. Sua meta principal é avançar na prática, na ciência e na profissão de gerenciamento de projetos. Além disto administra e coordena um programa de credenciamento mundialmente reconhecido que promove o desenvolvimento da profissão e da carreira. O mais conhecido deles é o Profissional de gerenciamento de projetos (PMP). | |
Project Management Professional | |
---|---|
Profissional de gerenciamento de projetos certificado pelo PMI. A Certificação Project Management Professional (PMP®) do PMI® é a credencial profissional mais reconhecida e respeitada em termos mundiais no que tange ao Gerenciamento de Projetos. | |
Propósito da Contagem | |
---|---|
Fornecer uma resposta para um problema de negócio. Determina o tipo e o escopo da contagem. Influencia o posicionamento da fronteira da aplicação. | |
Protótipo | |
---|---|
Protótipo é um produto que ainda não foi comercializado, mas está em fase de testes ou de planejamento. Para a engenharia de software, protótipo é um sistema/modelo sem as funcionalidades inteligentes (acesso a banco de dados, sistemas legados, regras de negócio, etc), apenas com as funcionalidades gráficas, e algumas funcionalidades básica para o funcionamento do próprio protótipo. Utilizado geralmente para obter aprovação de quem solicita o sistema. | |
PSM | |
---|---|
O PSM (Practical Software and Systems Measurement) é uma metodologia padrão para a implantação de processos de medição de software, compatível com o padrão ISO/IEC 15939 e com a Área de Processo “Measurement and Analysis” do CMMI. É patrocinado pelo Departamento da Defesa e pelo Exército dos EUA. Fornece detalhamento de todos os passos e tarefas para implementação de um programa de medição de software, além de lições aprendidas, estudos de caso e um guia de implantação. Inclui também um conjunto de medidas já utilizadas com sucesso pela indústria, em categorias previamente definidas: - Prazo e Progresso | |
Reconhecido pelo Usuário | |
---|---|
O termo reconhecido pelo usuário refere-se a requisitos definidos para processos e/ou grupos de dados que foram acordados e entendidos tanto pelo(s) usuário(s) quanto pelos desenvolvedor(es) de software. Por exemplo, usuários e desenvolvedores concordam que uma Aplicação de Recursos Humanos terá funcionalidade para manter e guardar informações do Funcionário na aplicação. | |
Refresh | |
---|---|
O processo de recriar um conjunto de dados para fazê-lo atualizado e em sincronia com a sua fonte original. | |
Reparo | |
---|---|
Requisito | |
---|---|
Condição ou capacidade necessária para que um stakeholder resolva um problema ou satisfaça um objetivo. Condição ou capacidade que necessita ser satisfeita ou possuída por uma solução ou componente de solução para satisfazer um contrato, padrão, especificação ou outros documentos formais impostos. Definição baseada no IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology | |
Requisito Funcional | |
---|---|
Subconjunto dos requisitos do usuário especificando o que o software deverá fazer em termos de tarefas e serviços. NOTA Os Requisitos Funcionais do Usuário incluem, mas não estão limitados a: Requisitos do usuário que não constituem Requisitos Funcionais do Usuário incluem, mas não estão limitados aos seguintes: [ISO/IEC 14143-1:2007, definition 3.8] | |
Requisitos Funcionais Finais | |
---|---|
São os requisitos originados de sessões conjuntas entre usuários e desenvolvedores. São a versão final dos requisitos e apresentam as seguintes características: linguagem comum aos usuários e desenvolvedores, completos, consistentes, viáveis e aprovados pelo usuário | |
Requisitos Iniciais do Usuário | |
---|---|
Representam os requisitos dos usuários antes das sessões entre os usuários e os desenvolvedores. Eles podem ter as seguintes características: incompletos, inviáveis de implementar, muito genérico, expresso na linguagem familiar ao negócio do usuário. | |
Requisitos não Funcionais | |
---|---|
Os requisitos não funcionais descrevem condições de ambiente sob as quais a solução deve funcionar, bem como atributos de qualidade da solução. Em suma, abordam COMO as funcionalidades serão oferecidas ao usuário. Usualmente são organizados em Categorias (ISO/IEC 9126, FURPS e FURPS+), pelas quais, através de suas características, fornecem o suporte para elicitação dos Requisitos Não Funcionais. A ISO/IEC 14143 não oferece definição para Requisito Não-Funcional do Usuário, mas apresenta alguns exemplos em uma nota. Exemplos de requisitos do usuário que são Requisitos Não-Funcionais do Usuário incluem, mas não estão limitados aos seguintes:
| |
Requisitos Técnicos Iniciais | |
---|---|
Representam a visão dos desenvolvedores de software dos requisitos criados a partir do estudo de viabilidade. Um trabalho dos desenvolvedores de software, dentre outros, é organizar os requisitos dentro das aplicações existentes, se existirem. Os Requisitos Técnicos Iniciais podem incluir elementos necessários para a implementação, mas não são utilizados na contagem de pontos de função. Por isso podem ter as seguinte características: dependência tecnológica, linguagem não familiar ao usuário, nem sempre aderente às necessidades do usuário. | |
Retorno sobre o Investimento | |
---|---|
Em finanças, retorno sobre investimento (em inglês, return on investment ou ROI), também chamado taxa de retorno (em inglês, rate of return ou ROR), taxa de lucro ou simplesmente retorno, é a relação entre o dinheiro ganho ou perdido através de um investimento, e o montante de dinheiro investido. | |
Reusabilidade | |
---|---|
Uma das 14 características gerais de sistema que descreve em que nível a aplicação e seu código foram especificamente projetados, desenvolvidos e suportados para serem utilizados em outras aplicações. Pontue o nível de influência de acordo com as seguintes orientações: | |
RUP | |
---|---|
O Rational Unified Process - RUP (ou Processo Unificado Rational) é um modelo de processo de desenvolvimento de software iterativo. Ele é passível de ser adaptado por qualquer organização, que pode buscar os elementos do processo mais adequado à suas necessidades. A Rational é uma divisão da IBM desde 2003. | |
Saída Externa | |
---|---|
Saída Externa (SE) ou External Output (EO) É um 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 pelo menos uma fórmula matemática ou cálculo, ou criar dados derivados, manter um ou mais arquivos lógicos internos (ALI) e/ou alterar o comportamento do sistema. | |
Scope Creep | |
---|---|
Funcionalidade adicional que não foi originalmente especificada nos requisitos do projeto, porém é identificada conforme o escopo vai sendo melhor esclarecido e as funções definidas. | |
Significativo | |
---|---|
Reconhecido pelo usuário e satisfazendo um Requisito Funcional do Usuário. | |
SLA | |
---|---|
Um Acordo de Nível de Serviço (ANS ou SLA, do inglês Service Level Agreement) é a parte de contrato de serviços entre duas ou mais entidades no qual o nível da prestação de serviço é definido formalmente. Na prática, o termo é usado no contexto de tempo de entregas de um serviço ou de um desempenho específico. | |
Stakeholder | |
---|---|
Stakeholder (em português, parte interessada ou interveniente), é um termo usado em administração que refere-se a qualquer pessoa ou entidade que afeta ou é afetada pelas atividades de uma empresa. Vide definição Wikipedia: http://pt.wikipedia.org/wiki/Stakeholder | |
Subgrupo Obrigatório | |
---|---|
Um dos dois tipos de subgrupos para um tipo de registro (registro lógico referenciado - RLR - ou record element type - RET). Subgrupo obrigatórios significa que o usuário deve usar um dos subgrupos durante um processo elementar que crie uma instância dos dados. | |
Subgrupo Opcional | |
---|---|
É aquele que o usuário tem a opção de não usar durante um processo elementar que inclui ou cria uma instância dos dados. | |
Surrogate | |
---|---|
Também conhecida como chave substituta. São campos sequenciais gerados automaticamente pelo banco de dados usados como chave primária para uma tabela, e que não têm conteúdo semântico para a aplicação nem relação com outros dados da tabela. | |
Tabela de Contribuição | |
---|---|
Tabelas de Complexidade | |||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||
Tamanho Funcional | |
---|---|
Tamanho do software resultante da quantificação dos requisitos funcionais do usuário (ISO 14143-1:2007). É a medida das funcionalidades de uma aplicação que o usuário solicita / recebe, tendo como base a Visão do Usuário. | |
Taxa de entrega | |
---|---|
É o inverso da produtividade, representa quantos insumos são necessários para se produzir uma unidade de produto. No contexto de desenvolvimento de software é normalmente expresso em HH/PF. | |
Tipo de Dado | |
---|---|
Campo único reconhecido pelo usuário e não repetido. Também chamado Dado Elementar Referenciado (DER) ou Data Element Type (DET). Regras para contagem em um arquivo lógico: - Conte um DER para cada campo único, reconhecido pelo usuário e não repetido, mantido ou recuperado pela função de dados durante a execução de todos os processos elementares no escopo da contagem. Regras para contagem em uma transação: - conte um tipo de dado para cada campo que entra ou sai pela fronteira da aplicação, na direção do usuário, e que seja necessário à execução do processo elementar. - conte um tipo de dado para a capacidade de especificar uma ação - conte um tipo de dado para a capacidade da transação de emitir uma mensagem para o usuário (seja de erro, aviso, alerta, confirmação, etc). | |
Tipo de Registro | |
---|---|
Um Tipo de Registro Elementar é um subgrupo de dados reconhecido pelo usuário dentro de uma função de dados. Pode ser um subgrupo opcional ou subgrupo obrigatório. Também chamado de registro lógico referenciado - RLR ou record element type - RET. A complexidade funcional de cada arquivo lógico é definida com base no número de tipos de dado (DET) e tipos de registro (RET) associados a ele. No contexto de modelagem de dados, é um grupo de itens de dados relacionados que são tratados como uma unidade. | |
Tipos de contagem | |
---|---|
Pode ser Projeto de melhoria, Projeto de Desenvolvimento e Aplicação. | |
Tipos de Função | |
---|---|
Os cinco serviços de informação básicos fornecidos ao usuário pela aplicação e identificados na análise de pontos de função. São entradas externas, saídas externas, consultas externas, arquivos lógicos internos e arquivos de interface externa. | |
UML | |
---|---|
A Unified Modeling Language (UML) é uma linguagem de modelagem aberta que permite que desenvolvedores visualizem os produtos de seu trabalho em diagramas padronizados. Junto com uma notação gráfica, a UML também especifica significados, isto é, semântica. É uma notação independente de processos, embora o RUP (Rational Unified Process) tenha sido especificamente desenvolvido utilizando a UML. A UML não é uma metodologia de desenvolvimento, o que significa que ela não diz o que fazer primeiro e em seguida ou como projetar um sistema, mas ela auxilia a visualizar seu desenho e a comunicação entre objetos.
| |
Usuário | |
---|---|
Qualquer pessoa ou coisa que se comunica ou interage com o software em qualquer momento. | |
VAFA | |
---|---|
É o fator de ajuste da aplicação depois que o projeto de melhoria estiver concluído (Value Adjustment Factor of the application After). Na fórmula do projeto de melhoria aEFP = [(ADD + CHGA + CFP) * VAFA] + (DEL * VAFB) Na fórmula da aplicação após o projeto de melhoria | |
VAFB | |
---|---|
É o fator de ajuste da aplicação antes do projeto de melhoria ter iniciado (Value Adjustment Factor of the application Before). Na fórmula do projeto de melhoria aEFP = [(ADD + CHGA + CFP) * VAFA] + (DEL * VAFB) | |
Valor do Fator de Ajuste | |
---|---|
Indica a funcionalidade geral fornecida pela aplicação ao usuário. É um valor percentual calculado a partir do nível de influência de cada uma das 14 Características Gerais do Sistema. Pode produzir uma variação de +/- 35% no tamanho do sistema. | |
Visão do Usuário | |
---|---|
Representa uma descrição formal das necessidades de negócio do usuário em sua própria linguagem. Desenvolvedores traduzem a informação do usuário em linguagem de tecnologia da informação para fornecer uma solução. Ela: - É uma descrição das funções do negócio. Nota 1: o termo desenvolvedor neste caso não se refere exclusivamente ao programador, mas a todos os profissionais envolvidos no processo de desenvolvimento do sistema (analista, documentador, testador, gerente de projetos, etc). Nota 2: Um documento técnico (em linguagem de TI) gerado pelo desenvolvedor pode ser usado para contar pontos de função se for possível extrair do mesmo os requisitos funcionais, no entanto ele não representará a visão do usuário pois não usa a linguagem do negócio do usuário. | |
Volume de Transações | |
---|---|
Uma das 14 características gerais de sistema que descreve em que nível o alto volume de transações de negócio influencia o projeto, desenvolvimento, instalação e suporte da aplicação. Pontue o nível de influência de acordo com as seguintes orientações: | |