Ambiente
Conjunto de hardware e software, com uma configuração específica, estabelecida para um propósito pré-definido (desenvolvimento, testes, etc.).
Ambiente de laboratório
Ambiente utilizado pela equipe de projeto (mais especificamente pelos desenvolvedores), com o objetivo de implementar a solução.
Ambiente de produção
Ambiente do cliente no qual o release final da aplicação será evetivamente implantado.
Ambiente de testes
Ambiente em que a corretude da solução, de acordo com suas especificações, é verificada. Ambientes de teste podem ser tanto do cliente como da equipe de projeto. Um ambiente de testes no cliente tem o objetivo de homologar a solução antes da mesma ser disponibilizada no ambiente de produção. Ambientes de teste da equipe de projeto, por sua vez, podem ser usados para a realização de testes unitários pelos desenvolvedores ou para a realização de testes mais complexos pela equipe de testes.
Aplicação
Software desenvolvido para resolver um problema específico.
Arquitetura em camadas
A arquitetura em camadas observa a organização da aplicação quanto a sua divisão em camadas e a independência entre estas; assim, pode existir uma camada formada por classes responsáveis por prover o acesso a base de dados, enquanto outra camada é responsável apenas pela implementação das regras de negócio da aplicação, e a independência entre elas é garantida através do uso de interfaces.
Área principal do repositório
É a linha de desenvolvimento principal (mainline) do repositório, onde todos os itens de configuração estão armazenados.
Artefato
Informação estruturada que é produzida, modificada ou utilizada por um processo. Define uma área de responsabilidade e é sujeito a controle de versão. Um artefato pode ser um modelo, um elemento do modelo, um documento ou arquivos do código fonte da aplicação.
Atividade
Unidade de trabalho que possui um responsável, alguns participantes, artefatos de entrada e saída e é dividida em passos.
Ator
Alguém ou algo que interage externamente com a aplicação ou o negócio.
Branch
Um branch é uma ramificação da área principal do repositório. Os itens de configuração do branch não deixam de existir na área principal, eles são duplicados (através de check-out para o branch).
Buffer time
Tempo adicionado ao cronograma pelo Gerente de Projeto para ajudar à equipe a acomodar atrasos decorrentes a problemas inesperados e mudanças. É tipicamente criado por estabelecer um deadline interno anterior ao que foi acordado com o cliente.
Bug tracking
Processo para registro de defeitos encontrados na aplicação, informando aos membros da equipe toda a informação relevante a estes.
Build
Versão operacional de uma aplicação que demonstra um subconjunto dos requisitos da aplicação a ser desenvolvida.
CASE - Computer Aided Software Engineering
Ferramenta de apoio ao desenvolvimento de software. Em linhas gerais, apóia a execução de atividades do desenvolvimento do software de forma automatizada. Em alguns casos, implementa um ambiente relativamente refinado no qual várias atividades de especificação ou codificação são apoiadas por recursos computacionais.
Caso de Uso
Representa uma funcionalidade da aplicação do ponto-de-vista do usuário. Consiste numa seqüência de ações que a aplicação executa e leva a um resultado observável para um ator específico. Um caso de uso possui os fluxos de eventos principais, alternativos e de exceções relacionados à produção do resultado observável.
Cenário
Instância de um caso de uso; subconjunto de um caso de uso. Pode corresponder ao seu fluxo principal ou a um fluxo secundário (alternativo ou de exceção).
Check-in
Ação de colocar um item de configuração no repositório, seja incluindo um novo item ou atualizando um já existente.
Check-out
Ação de fazer uma cópia de um item de configuração do repositório.
Classe
Descrição de um conjunto de objetos que compartilham as mesmas responsabilidades, relacionamentos, operações, atributos e semântica.
Cliente
Entidade ou empresa que arcará com os custos do projeto e tem interesse em agregar valor ao seu negocio utilizando a aplicação a ser desenvolvida.
Componente
Parte não-trivial, normalmente independente e substituível da aplicação, que atende a uma função clara no contexto de uma arquitetura bem definida. Um componente atende e provê a realização física de um conjunto de interfaces.
Defeito
Uma anomalia ou falha em uma aplicação, geralmente associado a um descumprimento de requisitos. São exemplos: omissões e imperfeições encontradas nos builds durante a fase de Desenvolvimento e nos Release Candidates. Um defeito deve ser monitorado e corrigido.
Desenvolvimento
Uma das cinco fases do projeto, ao lado das fases de Visão, Planejamento, Estabilização e Implantação. Exemplo de uso: "É durante a fase de Desenvolvimento que novas funcionalidades são adicionadas à aplicação".Conjunto de todas as atividades necessárias para a conclusão de um projeto, desde sua concepção até a sua implantação. Exemplo de uso: "Durante o desenvolvimento do projeto, a equipe deve estar concentrada na identificação e antecipação dos riscos".
Disciplina
Uma coleção de atividades relacionadas a uma área de conhecimento. Exemplos são: Requisitos, Implementação e Testes.
Diagrama de Seqüência
Diagrama que descreve um padrão de interação entre os objetos organizados cronologicamente; mostra os objetos que participam da interação através de suas "linhas de vida" e pelas mensagens que eles trocam uns com os outros.
Diagrama de subsistemas
O diagrama de subsistemas descreve como a aplicação está organizada em termos de subsistemas que conversam entre si para realização de um serviço, ou seja, uma grande aplicação pode ter um módulo responsável pela venda de produtos (um ponto de venda, por exemplo) que se comunica com o módulo de emissão de notas fiscais para emissão de notas, recibos, etc., além de interagir com o módulo de retaguarda que é responsável pelos flashes de venda, consolidação das vendas do dia, geração e distribuição de lotes, etc. Além disso, deve apresentar também a relação com outras aplicações externas (legadas, terceiros etc.).
Elicitar requisitos
Investigar e descobrir os requisitos da solução, sem descrição detalhada.
Equipe de Colaboradores
Princípio que defende a igualdade e importância de cada um dos papéis do Modelo de Equipe, atribuindo a todos a responsabilidade pelo sucesso ou fracasso do projeto.
Estágio de teste
Os estágios de teste classificam os testes de acordo a etapa do desenvolvimento da solução em que são realizados. Como conseqüência, cada estágio de teste possui objetivos diferentes. Possíveis estágios de teste são testes de unidade, testes de integração, testes de sistema e testes de aceitação.
Fase
Corresponde a um tempo do projeto durante o qual um conjunto de atividades é realizado, gerando artefatos e decidindo os próximos passos, determinando, ao seu final, um marco. Uma das cinco divisões do Modelo de Processos. São elas: Visão, Planejamento, Desenvolvimento, Estabilização e Implantação.
Inspeção de código
Acesso ao código produzido para melhorar sua qualidade e educar a equipe de desenvolvimento.
Integração Contínua
Boa prática de desenvolvimento de software, que prega uma constante integração do trabalho realizado por diferentes membros da equipe, objetivando a criação de builds diariamente ou em um intervalo de tempo ainda menor. Pode exigir um pouco de esforço e disciplina, mas seus benefícios são evidentes, principalmente quando é automatizada.
Item de configuração
É todo artefato que está sob a gerência de configuração, ou seja, é todo arquivo que está no repositório da ferramenta de gerência de configuração adotada, como arquivos de programa, arquivos texto, etc.
Iteração
Uma etapa completa passando pelas cinco fases do desenvolvimento do software: Visão, Planejamento, Desenvolvimento, Estabilização e Implantação.
Lock
Ação de bloquear um item de configuração por um responsável.
Macro-atividade
Atividades que são executadas conjuntamente para a realização de um objetivo. Fornecem um nível mais elevado de abstração na descrição do trabalho a ser realizado.
Marco
Ponto de sincronização e revisão durante o projeto. Momento em que a equipe pode visualizar seu progresso e realizar algumas correções.
Merge
Ação de fazer uma combinação de duas revisões de um mesmo item de configuração, para atualizá-lo no repositório.
Método
Modo regular e sistemático de realizar algo. Nível mais detalhado do processo.
Método de teste
Indica a abordagem do teste, explicitando o ponto de vista sob o qual o teste deve ser realizado.
Modelo de Equipe
Equipe de Colaboradores trabalhando independentemente, com responsabilidades multidisciplinares.
Modelo de Processos
Modelo de ciclo de vida do projeto que estabelece a ordem para todas as atividades a serem realizadas durante o desenvolvimento da aplicação.
MSF (Microsoft Solutions Framework)
Conjunto de práticas para planejar, construir e implantar soluções de tecnologia da informação. Ao contrário de uma metodologia, MSF é um framework flexível e escalável que atende as necessidades de uma organização ou time de qualquer tamanho. O MSF contém um conjunto de princípios, modelos e disciplinas para gerenciar pessoas, processos e elementos tecnológicos que a maioria dos projetos enfrentam.
Objeto
Entidade com limite e identidade bem definidos e que encapsula um estado e um comportamento. O estado é representado pelos atributos e relacionamentos. Já comportamento é representado pelas operações e métodos. Um objeto é uma instância de uma classe.
Padrão de Arquitetura
Descrição de um modelo arquitetural que soluciona um problema de projeto recorrente.
Papel
Nome dado a um conjunto de responsabilidades que serão atribuídas a membros do time.
Postmortem
Processo formal de revisão do que ocorreu com sucesso ou não durante o projeto. O objetivo é aprender lições para o futuro.
Política de controle de versão
Define normas e regras para manipulação e versionamento de arquivos com objetivo de manter a consistência das novas versões geradas.
Problema
Risco que se concretizou, impactando o sucesso do projeto.
Produto
Aplicação que não é desenvolvida para um cliente específico e sim genérico o suficiente para ser utilizado por diferentes clientes. Podem ser empacotados em CD-ROM, disponibilizados para donwload etc.
Processo
Conjunto de atividades, métodos, boas práticas e transformações utilizadas para desenvolver e manter um software e suas aplicações associadas.
Promoção
Ação de disponibilizar um item de configuração para os demais integrantes da equipe.
Release candidato
Release gerado na fase Estabilização que é considerado pronto para ser testado no ambiente de produção do cliente. Caso os testes sejam bem-sucedidos, este será o release final. Caso contrário, a aplicação sofre correções e um novo release candidato deverá ser gerado.
Release interno
É o processo de obter um estado conhecido do produto incrementalmente. A equipe usa releases internos para adicionar subconjuntos de funcionalidades ao produto até que ele seja completamente implementado.
Repositório
É uma área do servidor onde os itens de configuração estão fisicamente armazenados. É criado e mantido através da ferramenta de gerência de configuração adotada e mantém todas as revisões dos itens de configuração.
Requisito
Descrição de uma condição ou capacidade que a solução deve satisfazer, derivada diretamente das necessidades dos usuários e estabelecida em um contrato, padrão, especificação ou outro documento formal.
Responsável
Membro do Modelo de Equipe que responderá pelo sucesso ou insucesso da realização de uma atividade.
Revisão
É um termo muito utilizado nas ferramentas de gerência de configuração. Sempre que um componente é alterado e os check-out e check-in são executados diz-se que o componente foi revisado.
Risco
Evento com grande probabilidade de afetar negativamente o sucesso do projeto.
Script
São instruções que podem ser interpretadas pelo computador e têm a função de automatizar um determinado método.
Stub
Esqueleto de implementação de um pedaço de código utilizado temporariamente para desenvolver ou testar outro pedaço de código que depende dele.
Serviço
Unidade da aplicação lógica que inclui métodos para implementar uma operação, função ou transformação.
Solicitação de mudança
É qualquer alteração que se faça necessária na aplicação, seja para corrigir um defeito ou incluir uma nova funcionalidade.
Stakeholder
Qualquer pessoa ou representante de uma organização que tenha um interesse profundo no desenvolvimento do projeto ou cuja opinião deve ser acatada. São pessoas afetadas pela aplicação e que têm uma influência direta ou indireta nos seus requisitos. Um stakeholder pode ser um usuário final, o comprador, o contratante, um desenvolvedor ou um gerente de projeto.
Solução
Conjunto de artefatos desenvolvidos durante o projeto (como tecnologias, aplicação desenvolvida, documentação, treinamento e atividades de suporte) que atende com sucesso ao problema de negócio original dos clientes.
Subsistema
É uma parte de uma aplicação, que oferece serviços através de interfaces de comunicação. O conjunto de serviços oferecidos deve fazer sentido por si só, e não ser meramente um conjunto de serviços de apóio. Seus serviços são implementados por classes e outros subsistemas.
Tag
Tem a finalidade de identificar os componentes que compõem um build da solução. Quando um build da solução é gerado, todo artefato pertencente a este build recebem uma identificação (tag) fornecida pelo responsável.
Teste de aceitação
Nos testes de aceitação, é verificado se a solução obedece aos critérios definidos no Plano de Aceitação. Isso, geralmente, traduz-se na verificação da satisfação do cliente e do usuário com a solução como um todo (aplicação, documentos, treinamentos, etc.).
Teste de caixa branca
É uma abordagem de teste que analisa a estrutura interna do item a ser testado e seu comportamento, necessitando que o Desenvolvedor entenda sua implementação. Em testes que utilizem essa abordagem, devem ser observados todos (ou quase todos) os possíveis caminhos e condições de parada de um fluxo de eventos associado ao item testado.
Teste de caixa preta
É uma abordagem de teste que analisa o item a ser testado sob o aspecto funcional, observando apenas qual foi o resultado do teste e não como o mesmo foi obtido.
Teste de desenvolvimento
Testes de desenvolvimento são executados na fase de Desenvolvimento, sendo responsáveis por testar o que já foi implementado na aplicação de maneira integrada, com a intenção de procurar defeitos nos releases internos construídos pela equipe de desenvolvimento.
Teste de estabilização
Testes de estabilização são executados na fase de Estabilização, sendo responsáveis por testar a aplicação como um todo, integradamente, uma vez que seu escopo já foi completamente implementado.
Teste de integração
Testes de integração têm como objetivo garantir, em uma maior escala, que os casos de uso implementados (e testados por testes de unidade) estejam interagindo entre si conforme definido.
Teste de regressão
Testes de regressão são empregados quando uma versão nova é gerada e se deseja garantir que as funcionalidades da versão anterior são preservadas.
Teste de sistema
Testes de sistema verificam se a aplicação está funcionando como um todo. A integração da aplicação com o ambiente operacional similar ao de produção (hardware, pessoas e outras aplicações) é testada.
Teste de unidade
Testes de unidade são os únicos testes realizados por desenvolvedores, e não por testadores. Eles têm o objetivo de validar individualmente itens menores (classes ou métodos básicos) da implementação de um caso de uso.
Teste de validação do piloto
Teste conduzido em um subconjunto do ambiente de produção do cliente, em que a aplicação confrontada com situações e usuários reais. É o último teste pelo qual a aplicação passa antes de ser validada.
Teste de verificação imediata de build
Os testes de verificação imediata de build são aplicados a um build recém-criado com o objetivo de validá-lo como bem-sucedido e identificar defeitos, principalmente defeitos referentes à integração. Estes testes devem ser constituídos por, no mínimo, smoke tests (testes mais básicos). Entretanto, com um nível de automação adequado, testes de verificação imediata de build podem conter testes mais complexos, informativos e de maior cobertura
Thread
É um processo independente executando na máquina.
Unlock
Ação de liberar um item de configuração que estava bloqueado para um responsável.
Versão
É um termo genérico que pode ser usado tanto para aplicação quanto para componente. Sempre que há uma atualização na aplicação ou no componente em qualquer fase do desenvolvimento, é gerada uma nova versão. Uma versão pode ser uma revisão, um build, um release ou um baseline.
Viabilidade de cronograma
Avaliação de quão razoável está os prazos estimados do cronograma do projeto.
Viabilidade econômica
Avaliação de custo-eficiência de um projeto ou solução.
Viabilidade operacional
Medida do grau de adequação da solução para a organização. É também uma avaliação de como a equipe de desenvolvimento se sente diante do projeto.
Viabilidade técnica
Avaliação da praticidade de uma solução técnica específica e a disponibilidade dos recursos técnicos e dos especialistas.
Usuário
Pessoas que efetivamente interagirão com a solução. Este termo engloba, inclusive, os responsáveis pela instalação e suporte.
Usuário final
Usuários da solução que não são responsáveis pela instalação e suporte.