Engenharia de software

 

Análise e Projeto Estruturado


 

  • Análise estruturada → introduz o uso de ferramentas de documentação gráfica: lista de eventos, diagrama de contexto, diagrama de fluxo de dados, dicionário de dados, diagrama de entidade relacionamento, diagrama de transição de estado;
    • Diagrama de contexto (DC)
      • documenta o âmbito do estudo, identifica os limites dos processos, as áreas envolvidas, os relacionamentos com outros processos;
    • Diagrama de fluxo de dados (DFD)
      • nomeado também como: diagrama de fluxo de trabalho, diagrama de modelo funcional/de processo, diagrama de bolha;
      • representação gráfica (terminadores, entidades, fluxo de dados, depósitos), em rede dos processos e funções;
    • Diagrama entidade-relacionamento (DER)
      • visualização das entidades e relação entre elas;
    • Diagrama de transição de estado (DTE)
    • Especificação de processos
      • descreva a política representada por cada processo de baixo nível do DFD; (português estruturado, árvore de decisão)
    • Dicionário de Dados
      • define o significado dos fluxos e depósitos de dados;
      • define os valores e unidades relevantes de partes elementares dos fluxos e depósitos de dados;
      • define a composição de pacotes de dados que se movimentam pelos fluxos;
  • Projeto estruturado
    • Programação estruturada
    • Desenvolvimento top-down
    • Equipes de programação
    • Revisões estruturadas
  • Análise essencial → propõe o particionamento do sistema por eventos;
    • Modelo ambiental
      • define a fronteira, determinando o que interno a ele e externo a ele
      • Declaração de Objetivos
      • Diagrama de Contexto
      • Lista de Eventos
      • Dicionário de Dados Preliminar (opcional)
    • Modelo comportamental
      • DFD Particionado
      • Diagrama ER (DER)
      • Diagrama de Transição de Estado (DTE)
      • Dicionário de Dados Preliminar (opcional)
      • Especificações de processos

 

Engenharia de requisitos


 

  • Visão geral
    • Análise do problema → define o problema de acordo com as partes interessadas (stakeholders);
    • Levantamento dos requisitos → atores, casos de uso, necessidades;
    • Gerência de requisitos → gerenciar expectativas de mudanças;
  • Desafios
    • Objetivos que não estavam claros;
    • Ignorar um grupo de clientes;
    • Requisitos e especificações incompletos, indefinidos, incompletos ou inconsistentes (divergentes);
    • Demandas de mudanças fora do escopo;
  • Conceitos
    • Requisitos → constituem uma especificação das características e propriedades do sistema, o que inclui a descrição dos objetivos, comportamentos, restrições de operação;
    • Requisitos (IEEE) → uma condição ou capacidade necessitada por um usuário para resolver um problema ou alcançar um objetivo;
    • Especificação → descrição rigorosa e minuciosa das características (dos requisitos);
  • Coleta de Requisitos
    • Documentação → draft é um documento preliminar, porém completo, de requisitos para verificação de conflitos, relevância;
    • Classificação → agrupar os requisitos coletados em categorias bem definidas;
      • Funcionais → descreve as funcionalidades e comportamentos do sistemas;
      • Não-funcionais → descreve como deve ser implementado (qualidade, performance, usabilidade, segurança, confiabilidade, regras de negócio)
  • Análise dos Requisitos
    • Desafios
      • As partes interessadas (stakeholders) podem não conhecer o problema ou objetivos a serem alcançados, ou ainda, problemas ou objetivos conflitantes entre as partes;
      • Fatores políticos e organizacionais podem influenciar os requisitos do sistema, como a mudança das partes interessadas, que podem ocasionar uma nova perspectiva de escopo e eventual conflito de requisitos;
    • Solução de conflitos
      • identificar as partes interessadas no levantamento de cada requisito;
      • procurar acordo entre as partes geradoras de requisitos conflitantes;
    • Atribuição de prioridades → definir prioridades dos requisitos com as partes interessadas;
      • Requisitos essenciais → Requisitos Importantes → Requisitos Desejáveis
    • Validação
      • Confirmar a demanda das partes interessadas (comunicação apropriada);
      • Revisão dos requisitos → análise manual e sistemática;
      • Prototipação → esboço (rascunho) de telas que retratam às partes interessadas para validar os requisitos;
      • Geração de casos de teste → testes específicos para avaliar os requisitos;
  • Gerenciamento de requisitos → controle das mudanças dos requisitos;
    • Rastreamento de requisitos
      • identificar as dependências entre requisitos e suas origens (partes interessadas);
      • relaciona os requisitos com as interfaces internas e externas do sistema;
      • identifica a governabilidade de subsistemas;
      • faz uso da tabela de rastreabilidade;
    • Rastreamento de projeto
      • identificar partes do projeto relacionadas aos requisitos;
    • Matriz de rastreamento
      • por meio de hypertexto ou referência cruzada;

 

UML

 

  • Contexto histórico
    • OMTObject-Modeling Technique (James Rumbaugh, 1991)
      • método de análise para entendimento e simulação do problema, bem como visualização alternativa;
      • divide-se nos modelos objeto (classe e objeto), dinâmico (sequência e estado) e funcional (fluxo);
    • OOSEObject-oriented software engineering (Ivar Jacobson, 1992)
      • método de design (projeto) inclui artefatos que envolvem a visão do usuário;
      • divide-se nos modelos de requisitos, análise, design, implementação e teste (similar aos diagramas de casos de uso, sequência e estado);
    • OODObject-oriented Analysis and Design (Grady Booch, 1993)
      • método de design (projeto) inclui artefatos voltados a implementação e codificação;
      • divide-se nos diagramas de interação, sequência, módulos, classe, objeto e estado;
  • Introdução
    • Não é método ou metodologia, não é modelo, não é processo, não é uma linguagem natural;
    • Não depende de tecnologia, de paradigma de programação (não requer orientação a objetos) ou de linguagem de programação;
    • Fundamento → modelo é uma representação simplificada e abstrata a partir de determinada perspectiva¹ (conceito amplo);
    • UML → especialização da representação de modelos para descrever, expressar e comunicar ideias de sistemas, em alto nível de abstração;
    • Forma da UML → é uma linguagem visual² para visualização, especificação, construção e documentação em diagramas¹;
      • perspectivas estáticas → diagramas estruturais;
      • perspectivas dinâmicas → diagramas comportamentais;
      • ¹perspectiva → cada diagrama representa um diferente ponto de vista;
      • ²linguagem visual → menos ambígua que a linguagem natural e menos detalhada que o próprio código;
    • levantamento e análise de requisitos → suas etapas trabalham com o domínio do problema e compressão das necessidades e expectativas das partes interessadas;
    • prototipação → produzir obrigatoriamente um protótipo;
    • análise → determina o domínio do problema (funcionalidade e restrições);
    • projeto → determina o domínio da solução;
    • manutenção;
  • Linguagem para especificação de restrições em objetos (OCL)
    • Uma linguagem declarativa utilizada para descrever regras de negócio de forma mais precisa do que com o uso dos diagramas;
    • Reduz eventuais ambiguidades ou interpretações diversas daquela desenhada;
    • Possui sintaxe e semântica formais que podem ser traduzidas para códigos, scripts, etc;
  • Relacionamentos → relações lógicas entre elementos dos diagramas;
    • Associação simples (–––>) → instâncias de um objeto possuem instâncias de outro objeto;
      • Nome da associação;
      • Navegabilidade → direção de acessos aos dados; unidirecional (→)  ou bidirecional (↔ ou −);
      • Multiplicidade → número de ocorrências (1 ou *);
      • qualificada → identifica um atributo único ou chave primária (ex: CPF) em uma associação 1→* (ListaDePessoas[CPF] → Pessoa);
      • notação de linha sólida com ou sem setas;
    • Associação por agregação (–––◊) → Uma classe B (parte) pode ser usada por outras classes distintas de A◊––B (ex: A:time de futebol e B:pessoa); a parte pode ser compartilhada com outros relacionamentos, e não necessita ser excluída em cascata (não determina o ciclo de vida);
      • notação linha sólida com losango aberto ao lado da classe principal;
    • Associação por composição (–––♦) → Uma classe B (parte) existe especificamente ou pertence exclusivamente para atender a classe A♦––B (ex: A:empresa e B:departamento); a parte é exclusivo e não pode ser compartilhado com outro relacionamento; e é excluída em cascata (determina o ciclo de vida);
      • notação linha sólida com losango fechado ao lado da classe principal;
    • Dependência (– – –>) → indica que mudanças em um elemento pode causar mudanças no outro, como alterações em interfaces ou em pacotes;
      • notação linha tracejada com seta ao lado do elemento consequente;
    • Generalização (–––∇) →representa o conceito de herança, ou seja, relacionamento entre um objeto específico e outro genérico∇;
      • notação linha sólida com triângulo ao lado do elemento mais genérico;
    • Realização (– – –∇) → classe que implementa uma interface, um pacote que implementar outro pacote, etc;
      • notação linha tracejada com triângulo ao lado da interface∇;
      • notação linha sólida com circulo fechado que representa a interface;
    • Dependência e Realização (notação apenas)
      • notação linha sólida com bola-soquete; soquete representa a dependência, e a bola representa a interface;
  • Diagramas estruturais  → análise do sistema sob perspectivas estáticas;
    • Diagrama de classes
      • representa um conjunto de classes, interfaces e relacionamentos;
      • classes → formam-se por nome, as propriedades (atributos) e os comportamentos (operações) das classes do sistema;
        • o nível de detalhamento do diagrama é discricionário, podendo conter apenas o nome da classe até informações completas das propriedades;
        • as classes ou operações abstratas são apresentados em itálico;
        • as propriedades ou operações de classe (escopo estático) e são apresentados sublinhados, caso contrário, são de instância;
        • os comportamentos são formados pela visibilidade, nome da operação, nomes e tipos de parâmetros, tipo do retorno e {restrições}; a operação a definição do comportamento, o método é cada implementação da operação;
        • as propriedades são formadas pela visibilidade, nome do atributo, tipo do dado, multiplicidade[0..5] (número de elementos), valor padrão e {restrições};
      • interfaces → representa-se como classe com estereótipo <<interfaces>> ou pelo elemento Ο (bola) com nome embaixo;
      • modificadores de visibilidade
        • +pública → acessível por qualquer outra classe;
        • #protegida →acessível pela própria classe ou por suas subclasses;
        • ~pacote → acessível pelas classes que estão no mesmo pacote, incluindo a própria classe;
        • −privada → acessível pela própria classe;
    • Diagrama de objetos
      • representa os objetos a partir de um snapshot do sistema, equivalente a uma instância do diagrama de classe;
      • fornece uma visão (somente) dos valores dos atributos de cada objeto e vínculo entre os objetos, similar a um componente de depuração;
      • não contém as operações!
        • notação similar ao diagrama de classe, porém, possui apenas a listagem dos atributos (chave) e seus valores, bem como as ligações entre objetos;
    • Diagrama de componentes (partes implementáveis de um sistema)
      • um componente possui interfaces e comportamentos bem definidos (coesão e baixo acoplamento), pode ser uma classe, um subsistema, um aplicativo;
      • representa componentes implementáveis do sistema (módulos, código fonte, bibliotecas, formulários, arquivos de ajuda) e seus relacionamentos por meio de interfaces;
      • fornece uma visão da estrutura e interação dos componentes, seja em tempo de ligação (compilação) ou execução (comunicação);
        • notação por meio de retângulo com conector no canto superior direito;
    • Diagrama de pacotes (agrupamento de elementos UML)
      • representa as grandes divisões (pedaços) do software, como subsistemas ou submódulos e sua composição;
      • fornece agrupamentos lógicos de elementos UML para auxílio a demonstração da arquitetura ou a definição de camadas do sistema;
      • agrupa casos de uso, componentes, classes, e qualquer outro elemento UML;
        • notação por meio de um envelope com guia no canto superior esquerdo que contém o nome do pacote;
        • os elementos agrupados podem ser representados dentro do envelope ou em forma hierárquica cuja raiz é representada por ⊕;
    • Diagrama de implantação
      • representa as necessidade de configuração física (hardware) ou ambiente de execução (servidores de aplicação), incluindo estações de trabalho, topologias, e protocolos de comunicação;
      • artefatos → empacotamentos de software (arquivos war/ear), de código-fonte, de código binário, de executáveis (arquivos exe);
      • determina a distribuição dos módulos do sistema entre servidores por meio de nós (processamento e memória próprio) e artefatos;
        • notação por meio retângulos (navegador, cliente desktop, servidor web, servidor de aplicação) interligados pela forma de comunicação (http, RMI, JDBC);
    • Diagrama de estrutura composta
      • descreve a estrutura interna (classes, objetos e interfaces) de um classificador modelando colaborações;
      • descreve estruturas de partes (instâncias contidas em outro elemento) ou instâncias interconectadas por portas (ponto de interação entre os elementos);
      • usado para associar o diagrama de objetos com o diagrama de classes/interfaces em tempo de execução;
        • notação de um círculo tracejado (colaboração para execução de determinada atividade) que contém partes de diagramas de objetos e partes de classes estruturadas;
    • Diagrama de perfis (UML 2.2);
      • trata-se de um mecanismo de extensão simplificada da linguagem por meio da criação de tipos padronizados de estereótipos, valores rotulados e restrições;
      • permite adaptar os modelos UML para diferentes plataformas e domínios;
      • ao criar um diagrama de perfil define-se propriedades comuns a todo o sistema, e evita-se a especificação de estereótipos em cada classe;
  • Diagramas comportamentais → análise do sistema sob perspectivas dinâmicas, mudanças com o passar do tempo;
    • Diagrama de caso de uso → usado nas fases de levantamento e análise dos requisitos do sistema para:
      • descrever um conjunto de cenários (não especifica implementação);
      • identificar atores (pessoa, hardware, outro sistema) são sempre uma entidades externas ao sistema;
      • identificar ou apresentar funcionalidades e características (tornar claro os requisitos);
      • delimitar o escopo do sistema;
      • representar uma sequência de ações (fluxo alternativos, fluxos de exceção, etc), interações e relacionamentos entre atores, sistemas e entidades externas, a fim de gerar valor observável;
      • a documentação (≠diagrama) de um caso de uso não possui um formato específico;
      • elementos
        • stick man ou <<actor>> → representam os atores;
        • círculo → é um caso de uso, em que um diagrama é a representação gráfica formada por um conjunto de casos de uso;
        • inclui (– – –>) → o caso de uso incluído é de execução obrigatória e é incluído por mais de um caso de uso (A inclui – – –> B);
        • estende (– –>) → o caso de uso estendido é de execução opcional (A estende – – –> B);
      • tipos
        • concreto → é iniciado por atores e possuem um fluxo completo de eventos;
        • abstratos (em itálico) → não são referenciados (instanciados) por atores diretamente, sendo incluídos, estendidos ou generalizações;
    • Diagrama de atividade (workflow)
      • descreve os passos (ações) até a conclusão (nó final) de uma determinada atividade por meio de algoritmos, processos de negócio, fluxos de trabalho ou métodos;
      • elementos
        • nó inicial (círculo fechado);
        • ações (caixas) → * é usado para representar a concorrência dinâmica (ocorrência de um laço, durante o estado de ação);
        • fluxo (seta) → liga uma ação a outra;
        • decisões (losango) →indica controle por meio de expressões booleanas (não há processamento paralelo);
        • união (losango) → une os fluxos de uma decisão;
        • nó de bifurcação ou separação (barra horizontal) → indicam processamento paralelo;
        • nó de junção (barra horizontal) → conclui um processamento paralelo;
        • nó final (círculo semi-fechado);
        • swimlanes (raias) → determina qual entidade é responsável por cada ação (partição das ações por unidade de negócio);
    • Diagrama de máquinas de estado
      • representa os vários estados possíveis de um objeto individual;
      • a mudança (transição) de estado decorre de um evento interno ou externo ao sistema associado ou não a uma [condição de guarda];
      • estados aninhados → estados dentro de outro estado;
      • estados concorrentes → um estados distinto para cada região de concorrência a qual ele pertence;
      • fronteira da concorrência →separação de duas regiões que podem ser executadas em paralelo;
      • pseudo-estado de histórico → grava o estado em determinado momento;
      • elementos
        • estados → valores possíveis de um objeto (permanecem em um estado quanto satisfazem uma condição ou realiza determinada atividade);
        • transiçõeseventos podem implementar [condição de guarda] para executar uma ação durante a mudança de estado;
        • ações → são executadas em caso de mudança de estado;
        • atividades → são executadas durante um estado;
    • Diagramas de interação → análise do sistema sob perspectivas dinâmicas e seus relacionamentos (dinâmica entre objetos);
      • Diagrama de sequência
        • representa especificação da implementação ou regra de negócio para solucionar determinado problema;
        • ênfase na ordem temporal que as mensagens são trocadas entre os objetos;
        • participantes orientados no eixo horizontal e ordem temporal de cima para baixo;
        • elementos
          • evento gerador (círculo fechado) → inicia o processo modelado;
          • participante (retângulo com nome:tipo) → objetos ou atores;
          • linha de vida (linhas pontilhadas ou barra de ativação partir do participante) → período em que o participante existe;
          • mensagem (seta aponta para barra de ativação) → chamada de uma operação (método) de outro ou do próprio objeto (seta entre linhas de vida);
            • síncrona (linha sólida com seta fechada) → a conclusão da operação é necessária para continuar a execução;
            • assíncrona (linha sólida com seta aberta) → a execução independente da conclusão da operação;
          • barra de ativação → operação (método) chamada ou construtor em execução;
          • mensagem de retorno (linha pontilhada com seta aberta) → retorno da operação;
          • auto-chamada (mensagem, ativação, retorno) → chamada de operação do próprio objeto;
          • criação de participante (seta aponta para um participante);
          • destruição de participante (X no fim da linha vida) → auto destruição ou por meio de mensagem por outro objeto;
      • Diagrama de comunicação (colaboração)
        • fortemente associado (equivalente) a o diagrama de sequência, apenas com ênfase distinta;
        • representa especificação da implementação ou regra de negócio para solucionar determinado problema;
        • ênfase na ordem estrutural (relacionamento entre os objetos) que as mensagens são trocadas entre os objetos;
        • participantes posicionados livremente, com mensagens sequenciadas obrigatoriamente em virtude da ausência do eixo do tempo (vertical);
      • Diagrama de tempo (temporização)
        • descreve objetos cuja mudança de estado esteja relacionada a temporização, bem como a duração em que permanecem em determinado estado;
        • determina condições (restrições) temporais (tempo mínimo ou máximo) que implicam na mudança de estado do objeto;
      • Diagrama de interação geral (UML 2.0);
        • visão geral de um sistema ou processo de negócio;
        • usado para associar o diagrama de atividades (workflow) com o diagrama de sequência (comunicação ou tempo) em que o segundo é integra um ação (caixa) da atividade;
        • pode referenciar (ref) outros diagramas em vez de apresentar no mesmo diagrama;

 

Processos de desenvolvimento de software


 

  • Características do Software
    • Desenvolvido ou projetado por engenharia;
    • Mantém suas funcionalidades ao longo do tempo;
  • Ciclo de vida de software → considerar a natureza do projeto e da aplicação para definição de métodos, ferramentas, controles e produtos a ser entregues;
    • Ciclo de vida clássico (cascata) → modelo mais antigo com abordagem sequencial e sistemática;
      • Análise e engenharia de sistemas → levantamento de requisitos gerais, de hardware, pessoas, banco de dados
      • Análise dos requisitos → coleta de requisitos específicos do software
      • Projeto → estrutura de dados, arquitetura do software, detalhes procedimentais, caracterização de interfaces;
      • Codificação → implementação;
      • Testes → validação dos aspectos lógicos aderentes ao requisitos;
      • Manutenção → mudanças por erros, inconformidades, ajuste de desempenho;

 

Processo Unificado (UP)

 

  • Conceitos
    • originado da Engenharia de Software de componentes;
    • centrado na arquitetura, orientado por casos de uso e com foco na redução de riscos;
    • fluxo de processo iterativo e incremental, o que recepciona as mudanças necessárias durante o processo de desenvolvimento;
    • agrega um valor real à organização que necessita manter padrões relativos às comunicações externas e à comunicação com a equipe de desenvolvimento;
    • promove o uso de seis melhores práticas:
      • desenvolvimento iterativo;
      • gerencia requisitos;
      • arquiteturas de componentes;
      • modelagem visual (UML);
      • verifica a qualidade de software continuamente;
      • gerencia mudanças;
  • Perspectivas do Processo Unificado
    • Dinâmica ou horizontal (1º dimensão) → representa o aspecto dinâmico do processo, onde estão representadas suas fases e interações (ciclos), às quais estão associados marcos que determinam sua finalização;
      • Fases → Iniciação/concepção, Elaboração, Construção e Transição;
      • As iterações aprimoram o entendimento do problema por meio de refinamentos sucessivos;
    • Estática ou vertical (2º dimensão) → representam as disciplinas, que agrupam logicamente as atividades.
      • Disciplinas → Modelagem de negócios, Requisitos, Análise e design (projeto), implementação, teste, implantação, gerenciamento de configuração e mudanças, gerenciamento de projetos e ambiente;
      • As disciplinas estão presentes em todas as fases, apenas a disciplina de implantação não se encontra na fase de iniciação/concepção, ou seja, as demais disciplinas estão presentes em todas as fases, com maior ou menor pico de trabalho;
  • Fases e disciplinas do Processo Unificado → as disciplinas abrangem diversas fases, sendo separadas didaticamente pela fase em que ocorre maior pico de trabalho da disciplina;
    • Iniciação (concepção) → visão, riscos, caso de negócio, plano de desenvolvimento, plano de interação, casos de desenvolvimento, ferramentas e glossário;
      • Modelagem de negócios → descrição do negócio, identificação dos processos e no desenvolvimento do modelo de domínio;
      • Requisitos → definição formal dos requisitos;
    • Elaboração → protótipos, lista de riscos, atualização do casos de desenvolvimento, instalação das ferramentas, documento de arquitetura de software, modelo de design, modelo de dados, modelo de implementação, atualização da visão, atualizar o plano de desenvolvimento de software, avanço conclusivo do modelo de casos de uso, especificação de requisitos não-funcionais, teste implementados e executados, arquitetura para automação dos teste;
      • Análise e design (projeto) → modelos de arquitutura, modelos de componente, modelos de objeto e modelos de sequência;
    • Construção → sistema executável, plano de implantação, execução do conjunto de testes a cada release, manuais de usuário e treinamento, plano de iteração à fase de transição, atualização do modelo de design, refinamento dos casos de desenvolvimento, utilização de ferramentas da de construção e atualização do modelo de dados;
      • Implementação → protótipos (iniciação), esboços da arquitetura (elaboração), modelo de implementação e integração (construção) e correções de falhas (transição);
      • Teste → processo iterativo realizado em conjunto com a implementação e ao final dela;
      • Implantação → distribuição de uma versão do produto;
      • Gerenciamento de configuração e mudanças → Gerenciar Solicitações de Mudanças e Planejamento de Controle do Projeto e Configuração de Mudanças;
    • Transição → o sistema pronto, notas de lançamento (release), artefatos para instalação, conclusão do material de treinamento, material de suporte para aprendizagem, utilização e manutenção.
      • Gerenciamento de projetos → observa a abordagem empresarial de gerência de projetos;
      • Ambiente → disponibilização de ferramentas de software apropriadas as peculiaridades de cada projeto;

 

Extreme Programming (XP)

 

  • Características
    • Desenvolvimento iterativo e envolvimento extremo do cliente;
    • Todos os requisitos são expressos como cenários (histórias de usuário e casos de uso);
  • Valores
    • Comunicação
    • Simplicidade
  • Práticas
    • Jogo de planejamento;
    • Planejamento incremental;
    • Pequenas versões;
    • Metáfora;
    • Projeto simples;
    • Time coeso;
  • Conceitos
    • Histórias de usuário (cartão de história) → como um [papel do usuário], quero [meta], para que eu possa [motivo].
    • Abordagem extrema → novas versões compiladas várias vezes ao dia, e entrega de incrementos em poucas semanas;
    • TDD (Test Driven Development) → define a interface e o comportamento esperado para a funcionalidade;

 

SCRUM

 

  • Conceito
    • Scrum é um framework para gerenciamento de projetos ágeis;
    • centrado em valores e entrega reais do produto;
    • abordagem iterativa e incremental para otimizar a previsibilidade e o controle a riscos;
  • Pilares → Princípios pétreos
    • Transparência →
    • Inspeção →
      • Daily scrum (meeting)
      • Sprint Review e Sprint Planning
      • Spreint Retrospective
    • Adaptação →
  • Papéis
    • Product Owner →
    • ScrumMaster →
    • Time →

 

Métricas de software


 

  • Conceitos
    • Medida → unidade de contagem (tempo, custo, peso, etc);
    • Métrica → associação de medias (horas por ponto de função, etc);
    • Medição → coletar informações de medidas;
  • As métricas de software são associações de medidas quantitativas para mensuração e dimensionamento de fatores relevantes e que agregam valor ao projeto. Quando coletadas, analisadas e avaliadas a partir de referências históricas, pode-se:
    • estimar o esforço de desenvolvimento de requisitos;
    • analisar a viabilidade do escopo em relação ao cronograma e orçamentos disponíveis;
    • acompanhar o progresso do projeto (no cronograma, no orçamento, etc);
    • embasar decisões de ajuste de fluxo de trabalho (recursos, produtividade, etc);
    • rastrear riscos;
    • prever número de erros, de componentes ou de linhas de código;
    • medir habilidades da equipe e identificar áreas problemáticas;
    • medir desempenho da equipe para subsidiar análise de “make or buy” (comparação com o mercado);
    • medir o produto entregue em contratos de remuneração por resultado;
    • aplicadas ao processo de software com a intenção de melhoria contínua, e avaliação da qualidade do software;
    • identificar a eficiência do processo;
  • Princípios específicos (Pressman,1995; RIEDER,2003):
    • Coletar dados para avaliação de desempenho atribuindo essas responsabilidades a toda equipe envolvida no projeto.
    • Reunir dados de desempenho relativos à complementação do software.
    • Analisar os históricos de projetos anteriores para determinar o efeito desses fatores, prevenindo erros para projetos futuros.
  • Principais benefícios (Pressman,1995; RIEDER,2003):
    • Constatar a qualidade do produto.
    • Avaliar a produtividade das pessoas.
    • Ter uma base de estimativas (baseline).
    • Justificar pedidos de recursos e treinamento adicional, entre outros.
  • Classificação
    • Métricas diretas → pessoas, orçamento, trabalho, velocidade de execução (desempenho da equipe), memória utilizada, número de defeitos, linhas de código (LoC), pontos de casos de uso, pontos de função;
    • Métricas indiretas → qualidade, complexidade, eficiência, confiabilidade, manutenabilidade das funcionalidades, tempo entre falhas, incidentes, problemas;
  • Tipos de métricas
    • Métricas orientadas a tamanho → a partir da quantidade de linhas de código, outras métricas de qualidade ou produtividade podem ser derivadas desta técnica;
      • não há padronização em contagem;
      • não tem significado de negócio;
      • difícil de estimar nas fases iniciais do projeto;
      • depende da linguagem de programação;
    • Métricas orientadas a função → a partir da quantidade de funcionalidades (tamanho funcional);
      • a partir do ponto de vista do usuário;
      • independe de linguagem de programação ou tecnologia;
      • pode omitir complexidade não visível;
    • Métricas orientadas a objetos → a partir de quantidade de cenários, classes-chave, classes de apoio, média de classes de apoio para cada classe-chave, subsistemas;

 

Análise por ponto de função

 

  • Contexto histórico
    • Allan Albrecht propõe as bases da análise de pontos de função;
    • Necessidade de medir projetos de diferentes linguagens de programação;
    • IFPUG promove o uso da APF, mantém o Manual de Práticas de Contagem (CPM) e provê estudos de casos;
    • ISBSG mantém repositório público de métricas de projetos de software;
  • Visão geral
    • IFPUG classifica a contagem em projeto de desenvolvimento, melhoria e aplicação;
    • NESMA classifica a contagem em:
      • detalhada → contagem de funções, entrada, saídas, e determina a complexidade;
      • estimativa → não analisa a complexidade (funções de dados → baixa, funções transacionais → média);
      • indicativa → estimativa de alto nível que conta somente funções de dados (considera 3ee, 2se, 1ce por arquivo lógico);
      • considera o fator de impacto para amortizar a contagem de melhoria de software;
  • Manual de práticas de contagem (CPM)

    • Guia de contagem com metodologias e técnicas mais usadas;
    • Busca tornar o processo de contagem:
      • simples o suficiente para minimizar a sobrecarga por medir;
      • consistente dentre vários projetos e organizações;
      • menos subjetivo, inclusive com a utilização de exemplos;
    • Conformidade com a norma ISO/IEC 14143:2007 (elementos gerais de métodos de contagem);
    • V3.0 → consolidação em documento único das diversas regras e interpretações;
    • V4.0 → introduziu a estimativa de contagem nas fases iniciais do ciclo de vida, a contagem de GUIs, exemplos e estudos de casos;
    • V4.2 → limitou-se a aprimorar interpretações de regras existentes;
    • V4.3.1 (norma ISO 20.926) → tornou o fator de ajuste opcional;
  • Análise de ponto de função

    • quantifica o tamanho (tarefas e serviços) e a complexidade de um projeto de software;
    • por meio da análise dos requisitos funcionais do projeto lógico (arquitetura lógica) da aplicação;
    • funcionalidades implementadas, solicitadas e recebidas pelo usuário;
    • funcionalidades impactadas pelo desenvolvimento, melhoria e manutenção;
    • aplicável a todos os domínios funcionais (áreas de negócio);
    • Usuário → qualquer entidade que interage com o software (pessoas, hardware, dispositivos, outros sistemas, etc);
    • Visão do usuário → representa suas necessidades e descreve as funções do negócio;
  • Limitações
    • não mede requisitos não funcionais (inclusive mudanças somente não funcionais tem ponto de função igual a zero);
    • projetos de pontos de função similares podem ter esforços e custos diferentes;
  • Finalidades
    • antes do projeto → estimar o tamanho e custo dos requisitos;
    • durante o projeto → acompanhar a evolução do desenvolvimento ou manutenção;
    • após o projeto → verificar o tamanho e custo das funcionalidades entregues;
    • fator de normalização para comparação de software, inclusive para mensurar os pacotes de software em aquisição;
    • apoiar a análise da qualidade e da produtividade;
    • reduzir a complexidade da gestão de contratos (tamanho, defeitos, esforço, tempo e custo);
  • Processo de medição funcional
    1. Reunir documentação disponível;
    2. Determinar o escopo, a fronteira da contagem, e identificar os requisitos funcionais do usuário;
    3. Medir funções de dados;
    4. Medir funções de transação;
    5. Calcular o tamanho funcional;
    6. Documentar e reportar;
  • Reunir documentação disponível
    • Necessita de documentação suficiente para subsidiar a contagem funcional;
    • Documentos de requisitos;
    • Diagrama de entidades e relacionamentos (suficientes para contagem de função de dados);
    • Diagramas de classe e sequência (são suficientes);
    • Modelos de dados e objetos;
    • Exemplos de relatórios gerados pela aplicação;
    • Guias, manuais de uso, materiais de treinamento;
    • Especialistas ou usuários na aplicação;
  • Determinar o escopo, a fronteira da contagem, e identificar os requisitos funcionais do usuário;
    • Identificar o propósito da contagem
      • deve ser motivada por questão de negócio;
    • Identificar o tipo da contagem
      • Projeto de desenvolvimento
        • desenvolvimento inicial do software;
        • contagem estimada que ocorre em diversas fases do desenvolvimento (análise, construção, etc);
        • mede o que será entregue ao usuário;
      • Projeto de melhoria
        • desenvolvimento de manutenções do software;
        • medem-se as funcionalidade adicionadas, alteradas ou removidas;
        • manutenção adaptativa → atende a mudanças no ambiente;
        • manutenção corretiva → corrige falhas no software;
        • manutenção perfectiva → aprimora a usabilidade, o desempenho, a documentação, etc;
      • Contagem de aplicação (determina o tamanho funcional instalado)
        • contagem precisa das funcionalidades atualmente fornecidas ao usuário;
    • Determinar o escopo da contagem
      • está vinculado ao propósito da contagem;
      • pode ser de toda a aplicação ou parcial (somente as funções utilizadas por usuário ou específicas de relatórios, etc.)
    • Determinar a fronteira de cada aplicação
      • fronteira é uma interface conceitual entre o software e seus usuários;
      • define o que é externo à aplicação;
      • interface a passagem (entrada e saída) dos dados;
      • está vinculada a separação dos processos de negócio;
      • depende da visão do usuário;
      • independe de implementação;
    • Identificar os requisitos funcionais
      • APF considera apenas os requisitos funcionais (funcionalidades e serviços);
      • Descartar os requisitos não funcionais (restrições ou qualidades específicas do sistema);
  • Medir funções de dados → sempre dados reconhecidos pelos usuários;
    • Identificar tipo das funções de dados → Representa a necessidade de armazenamento de dados ou de informações de controle;
      • Arquivos lógicos internos (ALI)
        • grupo de dados ou informações de controle logicamente relacionados e reconhecidos pelo usuário;
        • mantido dentro da fronteira da aplicação medida;
        • é um conceito lógico que relaciona-se a visão de negócio;
        • pode representar um ou vários arquivos, registros, tabelas ou objetos em um banco de dados;
      • Arquivos de interface externas (AIE)
        • grupo de dados ou informações de controle logicamente relacionados e reconhecidos pelo usuário;
        • referenciados pela aplicação medida, porém mantido dentro da fronteira de outra aplicação;
        • trata-se de um ALI de outra aplicação;
    • Contar DERs e RLRs para cada função de dados (ALI ou AIE)
      • Dado elementar referenciado (DER)
        • atributo único (nome, cpf, etc), não repetido e não recursivo
        • menor unidade de dado com nome que tem significado no mundo real;
      • Registro lógico referenciado (RLR)
        • especialização de ALIs em subgrupos¹ de dados relacionados que são tratados como uma unidade;
        • ocorrem em relacionamento entre entidades, como em heranças (pessoa, servidor¹, terceirizado¹, estagiário¹) e entidades fracas (pessoa e dependente);
    • Determinar a complexidade funcional de cada função de dados
      • ↓RLRs/→DERs  1–19   20–50   >50
        • 1……………: baixa    baixa  média
        • 2–5………..: baixa    média   alta
        • >5…………: média     alta    alta
    • Determinar o tamanho funcional de cada função de dados
      • ↓Complexidade  ALI  AIE
        • baixa…………:    7      5
        • média………..:  10     7
        • alta……………:  15    10
  • Medir funções de transação
    • Identificar cada processo elementar requerido pelo usuário;
      • Representa a necessidade de processamento de dados ou de informações de controle;
      • Processo elementar (componente funcional básico) é a menor unidade de atividade significativa, e constitui uma transação completa (todos os dados obrigatórios de uma entidade) e auto-contida;
    • Classificar cada processo elementar em função de transação;
      • Entradas Externas (EE)
        • processo elementar que processa de dados ou informações de controle enviados para fora da fronteira da aplicação;
        • modifica o comportamento da aplicação;
        • inclusão (create), alteração (update) e exclusões (delete) de dados dos ALI (inclusive em batch);
        • pode apresentar mensagem de confirmação da operação;
      • Consultas Externas (CE)
        • processo elementar que envia dados ou informações de controle para fora da fronteira da aplicação;
        • apresentação de dados (read), consulta e imprime, sem a utilização de cálculos ou algoritmos, a partir de ALI ou AIE;
        • como consultas de dados persistidos, relatórios, downloads sem cálculos adicionais a formatação;
        • somente formata e apresenta dados armazenados, podendo receber dados como filtro da consulta;
      • Saídas Externas (SE)
        • processo elementar que envia dados ou informações de controle para fora da fronteira da aplicação;
        • inclui lógica de processamento adicional (sumarização, totalização, agregação, etc), além daquela de uma consulta externa;
        • secundariamente, pode alterar o comportamento da aplicação (incrementar um contador, etc) ou manter ALIs;
        • apresentação de dados (read), consulta, calcula e imprime, com a utilização de cálculos ou algoritmos, a partir de ALI ou AIE;
        • como relatórios estatísticos, download com percentual calculado;
    • Contar DERs e ALRs para cada função de transação (EE, CE ou SE);
      • Dado elementar referenciado (DER)
        • cada dado que atravessa a fronteira durante o processamento da transação;
      • Arquivo lógico referenciado (ALR)
        • ALI ou AIE lidos (CE ou SE) ou gravados (EE) por função de transação;
    • Determinar a complexidade funcional de cada função de transação
      • Entradas Externas (EE)
        • ↓ALRs/→DERs   1–4       5–15    >15
          • 0–1…………: baixa     baixa   média
          • 2…………….: baixa    média    alta
          • >2………….: média     alta      alta
      • Consultas Externas (CE) ou Saídas Externas (SE)
        • ↓ALRs/→DERs  1–5      6–19    >19
          • 0–1………..: baixa    baixa   média
          • 2–3………..: baixa    média    alta
          • >3…………: média    alta      alta
    • Determinar o tamanho funcional de cada função de transação;
      • ↓Complexidade  EE   CE   SE
        • baixa…………:   3     3     4
        • média………..:   4     4     5
        • alta……………:   6     6     7
  • Calcular o tamanho funcional (contagem bruta de pontos de função)

    • Unidades de cálculo
      • Tamanho das funções adicionadas ao projeto (ADD);
      • Tamanho das funções alteradas ao projeto (CHGA);
      • Tamanho das funções excluídas (DEL);
      • Tamanho das funções de conversão de dados (CFP) → construídas no momento da implantação e descartadas após a utilização;
    • Cálculo para Projeto de Desenvolvimento (DFP = ADD + CFP)
    • Cálculo para Projeto de Melhoria (EFP = ADD + CHGA + DEL + CFP)
    • Cálculo para Contagem de Apliação (AFP) → tamanho das funções entregues ao usuário;
    • Resumo do tamanho funcional
      • ↓Complexidade  EE   CE   SE    ALI  AIE
        • baixa…………:     3     3     4     7      5
        • média………..:     4     4     5   10     7
        • alta……………:     6     6     7   15    10
  • Documentar e reportar
    • A documentação da contagem permite sua conferência e auditoria;
    • Deve estar adequada ao propósito da contagem;
    • Deve preservar a memória de cálculo além do número final da contagem;
    • Recomenda-se conter: o propósito, o tipo, o escopo, a fronteira, a data, as funções (tipo e complexidade) e o resultado da contagem;
    • Recomenda-se manter um padrão ao reportar os resultados e identificar a técnica utilizada;
      • 170 FP (IFPUG ISO/IEC 20.926)
  • Ajuste de pontos de função
    • Ajuste nos pontos de função brutos a partir de aspectos técnicos ou não funcionais;
    • Refletem a complexidade técnica de desenvolvimento do sistema;
    • Fatores subjetivos, podem estar desatualizadas, não contempla todos os fatores técnicos possíveis;
    • Nível de Influência → classifica as características gerais quanto ao esforço de desenvolvimento;
      • peso 0 → não presente ou sem influência;
      • peso 1 → influência mínima;
      • peso 2 → influência moderada;
      • peso 3 → influência média;
      • peso 4 → influência significativa;
      • peso 5 → influência forte;
    • Características gerais do sistema;
      1. Comunicação de dados → classifica os protocolos de comunicação de dados;
      2. Processamento distribuído → classifica a transferência de dados entre seus componentes físicos;
      3. Desempenho → classifica o tempo de resposta e volume de processamento;
      4. Utilização do equipamento → classifica as restrições de recursos computacionais de execução (capacidade do hardware);
      5. Volume de transações → classifica a taxa de transações de negócio;
      6. Entrada de dados on-line → classifica o volume de dados informados ou recuperados por transações interativas;
      7. Eficiência do usuário final → classifica os fatores humanos e facilidade de uso da aplicação;
      8. Atualização de dados on-line → classifica o volume de atualização dos ALIs por transações interativas;
      9. Processamento complexo → classifica a lógica de processamento utilizada (cálculos matemáticos, restrições de segurança, etc);
      10. Reusabilidade → classifica a possibilidade de reutilização de código em outras aplicações;
      11. Facilidade de implantação → classifica a conversão de ambientes anteriores;
      12. Facilidade operacional → classifica a facilidade técnica (automatização) de aspectos operacionais (inicialização, backup e recuperação);
      13. Multiplicidade de locais → classifica o grau de portabilidade desenvolvida (diferentes ambientes de hardware e software);
      14. Facilidade de mudanças → classifica a flexibilização (parametrização implementada) para permitir a modificação da lógica de processamento ou estrutura de dados;
    • Nível de Influência Geral (TDI)

      • soma da pontuação de todos os 14 itens (máximo de 14×5=70pts);
    • Variação pelo tamanho do projeto (VTP) → varia de 0,65 (padrão) até 1,35;
    • Fator de ajuste (FA) → (TDI * 0,01) + 0,65
      • um por cento do Nível de Influência Geral + Variação pelo tamanho do projeto;
      • máximo [0↔0,7] + [0,65↔1,35] ∴ [0,65↔2,05];
      • se FA = 1, então PFNA = PFA;
    • Pontos de função ajustados (PFA) → PFNA * FAPF
  • Cálculos derivados na APF
    • Índice de produtividade hipotético (IP) → PFA / E
      • considera experiência na plataforma;
      • média = 12h/PF
    • Estimativa de esforço (E) → PFA * IP
      • 180PF*12h/PF=2160HH (homens hora);
    • Tempo ótimo de desenvolvimento em meses (TD) → PFA^expoente de tipo de projeto (ex: 0,34)
      • 150PF^0,34=5,5meses
      • 195PF^0,34=6meses
      • É impossível terminar o trabalho antes de 0,75 * TD
    • Estimativa da equipe → E / TD * 22d * 7h (período de trabalho)
    • Backfiring → estimativa de pontos de função a partir do número de linhas de código baseada em um fator de conversão dependente da linguagem;
      • apresenta erros consideráveis por assumir uma relação linear entre pontos de função e linhas de código;
      • diferentes organizações divulgam fatores de conversão distintos para cada linguagem de programação;
      • útil para sistemas legados, em que uma contagem manual de pontos é inviável na prática e a precisão não seja um fator crítico;

 

Análise por ponto de caso de uso (UCP – Use Case Points)

 

  • Visão geral

    • Pontos por caso de uso é um método de contagem similar a APF, porém conta-se atores e casos de uso;
    • Não pode ser utilizada antes de concluída a análise de requisitos;
    • Aplica-se somente a projetos que utilizem casos de uso;
    • Ajustes realizados por complexidade técnica e ambiental (subjetivos);
    • Valor total de pontos do sistema (UCP) = UUCP x TCF x ECF
    • O peso total não ajustado (UUCP) = ∑ pesos de atores não ajustados (UAW) e pesos de casos de uso não ajustados (UUCW);

 

Testes de software


 

  • Objetivo → encontrar os erros;
  • Características
    • Operabilidade;
    • Observabilidade;
    • Controlabilidade;
    • Decomponibilidade;
    • Simplicidade;
    • Estabilidade;
    • Compreensibilidade;
  • Estratégias de testes
    • Fornecer um roteiro;
    • definir equipe para elaboração do roteiro;
    • verificação do conjunto de tarefas por função;
  • Modelo V de testes (Desenvolvimento ← Teste)
    • Especificação de requisitos ← Teste de aceitação ↑;
    • Projeto de alto nível ← Teste de sistema ↑;
    • Projeto detalhado ← Teste de integração ↑;
    • Codificação ← Teste de unidade ↑;
  • Tipos de teste
    • Teste caixa-branca (estrutural ou caixa de vidro)
      • projetado em função da estrutura do componente (depende da implementação);
      • perspectiva interna, código fonte ou circuito, definição de entradas e análise da lógica;
      • exercita todas as decisões lógicas;
      • aplicável nas fases de unidade (tipicamente), integração, regressão e sistema;
      • não analisa a especificação ou a lógica de especificação;
    • Teste do caminho básico (uma técnica de caixa-branca)
      • identifica a complexidade lógica para descobrir os caminhos básicos, afim de verificar se todos os caminhos são executados;
    • Teste caixa-preta (funcional)
      • projetado em função dos requisitos funcionais (independe da implementação);
      • não há acesso ao código fonte;
      • identifica funções incorretas ou ausentes;
    • Teste baseado em modelo;

 


Reinaldo Gil Lima de Carvalho