Please enable JavaScript.

Coggle requires JavaScript to display documents.

EC206 - Engenharia de software II (Cap. 1 - Métricas de Produto (Métricas…

- - - - Medição é o ato de determinar uma medida. Ex.: 10 bugs
      - Métrica de software relaciona as medidas individuais de alguma maneira. Ex.: 1 bug / 100 LOC
      - Indicador é uma ou mais métricas que proporcionam informações sobre o processo, projeto ou produto de software, permitindo a realização de ajustes e inclusão de melhorias.
        Ex.: 1 bug/200 LOC nos últimos 12 meses
    - - Formulação (criação)
        
        É a criação de medidas e métricas de software apropriadas para a representação do software considerado
      - Coleção (acúmulo)
        
        É o mecanismo usado para acumular dados necessários para criar as métricas formuladas
      - Análise (cálculo)
        
        É a computação das métricas e a aplicação de ferramentas matemáticas
      - Interpretação (avaliação)
        
        É a avaliação de métricas que resultam em informações sobre a qualidade da representação
      - Feedback (recomendações)
        
        São recomendações derivadas da interpretação de métricas de produto transmitidas para a equipe de software
  - - - Derivados usando uma relação empírica sobre medidas de contagem do domínio de informação do software e avaliação de sua complexidade. (EI, EO, ILF, EIF, EQ)
      - FP = N [0,65 + 0,01 E(Fi)
    - - baseada na consistência da interpretação de cada requisito por parte dos revisores. Quanto mais próximo de 1, menor a ambiguidade da especificação (mais peculiar).
      - Nr = Nf + Nrf
        Nf: requisitos funcionais
        Nrf: requisitos não funcionais
      - Q = Nui / Nr
        Nui: requisitos para os quais todos os revisores tiveram a mesma interpretação
  - - - Complexidade estrutural:
        
        Calculada sobre a quantidade de módulos no sistema
        
        S(i) = E[Fout(i) ^ 2]
        E é um somatório
        Fout(i) é o número de módulos imediatamente subordinados ao módulo i
      - Complexidade de dados:
        
        complexidade interna de um módulo
        
        D(i) = V(i) / [Fout(i) + 1]
        V(i): número de variáveis de entrada e saída do módulo
      - Complexidade de sistema:
        
        C(i) = S(i) + D(i)
        
        À medida que os valores de complexidade aumentam, a complexidade global de arquitetura do sistema também aumenta. Isso leva a uma maior probabilidade de que o trabalho de integração e teste também aumente.
    - - Extensão da árvore de herança - Depth of the Inheritance Tree (DIT)
        
        É o comprimento máximo desde o nó estudado até a raiz da árvore
        
        À medida que a DIT cresce, é possível que
        classes de nível inferior herdem muitos métodos.
        Isso causa dificuldades potenciais quando se
        tenta prever o comportamento de uma classe.
        
        Uma hierarquia de classe profunda (com DIT
        grande) também leva a uma complexidade maior
        no projeto.
        
        No lado positivo, grandes valores DIT implicam
        que muitos métodos podem ser reutilizados.
      - Número de filhas - Number of Children (NOC)
        
        Conforme cresce o número de filhas, a
        reutilização de código aumenta, mas a abstração
        representada pela classe pai pode ser diluída se
        algumas das filhas não forem membros
        apropriados da classe pai.
        
        Conforme o NOC aumenta, a quantidade de
        teste (necessário para exercitar cada filha em
        seu contexto operacional) também aumentará.
        
        É o número de classes filhas da classe estudada.
      - Acoplamento entre objetos de classes - Coupling Between Object Classes (CBO)
        
        É o número de colaborações listadas para uma classe.
        
        À medida que o CBO aumenta, é possível que a reutilização de uma classe diminua.
        
        Altos valores de CBO complica realizar mudanças e criar seus respectivos testes.
        
        Os valores de CBO para cada classe deverão ser mantidos o mais baixos possível;
        é consistente com a diretriz de reduzir o acoplamento em software convencional.
      - Resposta para uma classe - Response for a Class (RFC)
        
        O conjunto de respostas de uma classe é “um conjunto de métodos que podem
        potencialmente ser executados em resposta a uma mensagem recebida por um
        objeto daquela classe” [Chi94]. RFC é o número de métodos neste conjunto.
        
        Conforme a RFC aumenta, a complexidade geral de projeto (e, consequentemente,
        o trabalho necessário para o teste) aumenta.
      - Falta de coesão em métodos - Lack of Cohesion in Methods (LCOM)
        
        Cada método dentro de uma classe C acessa um ou mais atributos.
        
        É a qtd. de métodos que acessam um ou mais dos mesmos atributos.
        
        Se for alto, métodos podem ser acoplados uns aos outros via atributos.
        
        É desejável manter a coesão alta; isto é, manter LCOM baixo.
      - Tamanho de classe - Class Size (CS)
        
        número total de operações (operações de instancias herdadas e privadas)
        que são encapsuladas dentro da classe
        
        número de atributos (atributos de instancias herdadas e privadas) que são encapsulados pela classe
    - - Promovem respostas quantitativas para
        questões essencialmente qualitativas
      - Métricas de Interface:
        
        Esforço de click de mouse, esforço de digitação etc.
      - Métricas de Estética:
        
        Total de links, total de palavras etc.
      - Métricas de conteúdo:
        
        Espera de página, complexidade gráfica etc.
      - Métricas de Navegação
        
        Densidade de conectividade etc.
  - - - Quanto mais alto o valor de LCOM, mais estados precisam ser testados para garantir que os métodos não gerem efeitos colaterais.
    - - Atributos públicos são herdados de outras classes e, portanto, são visíveis aquelas classes.
      - Atributos protegidos são acessíveis a métodos em subclasses
      - Essa métrica indica a porcentagem de atributos de classe públicos ou protegidos.
      - Altos valores para PAP aumentam a probabilidade de efeitos colaterais entre classes porque atributos públicos e protegidos levam a um alto potencial de acoplamento.
      - Os testes devem ser projetados para garantir que esses efeitos colaterais sejam descobertos.
    - - Essa métrica indica o número de classes (ou métodos) que podem acessar atributos de uma outra classe, uma violação do encapsulamento.
      - Altos valores de PAD levam a efeitos colaterais em potencial entre classes.
      - Os testes devem ser projetados de forma que garantam que esses efeitos colaterais sejam descobertos.
    - - Essa métrica é uma contagem das hierarquias distintas de classe descritas no modelo de projeto.
      - Devem ser desenvolvidos conjuntos de testes para cada classe-raiz e hierarquia de classe correspondente
      - À medida que o NOR aumenta, o trabalho de teste também aumenta.
    - - Quando usado no contexto orientado a objeto, fan-in na hierarquia de herança é uma indicação de herança múltipla.
      - FIN > 1 indica que uma classe herda seus atributos e operações de mais de uma classe-raiz.
      - É uma situação que deve ser evitado sempre que possível.
    - - Métodos de superclasse terão de ser retestados para cada subclasse.
  - - - SMI = [Mt - (Fa + Fc + Fd)] / Mt
        Mt: número de módulos na versão atual
        Fc: número de módulos na versão atual que foram alterados
        Fa: número de módulos na versão atual que foram acrescentados
        Fd: número de módulos da versão anterior que foram excluídos da atual
      - À medida que o SMI se aproxima de 1.0, o produto começa a estabilizar.
      - O SMI pode ser usado também como uma métrica para planejamento de atividades de manutenção de software.
      - Tempo médio para produzir uma versão de um software pode ser relacionado com o SMI, e podem ser desenvolvidos modelos
        empíricos para o trabalho de manutenção.
- - - - Devem ser coletadas em todos os projetos e por longos períodos de tempo.
      - Visam a melhoria contínua do processo
      - Usadas para fins estratégicos
      - O processo está no centro do triângulo que conecta três fatores (Produto, pessoas e tecnologia) que possuem uma
        profunda influência sobre a qualidade do software e desempenho organizacional.
    - - Privadas
        
        Devem servir apenas como indicador individual, como forma de motivação. Ex.: taxa de defeito por pessoa.
      - Públicas
        
        São coletadas para avaliação de desempenho do time e do processo. Ex.: quantidade de bugs.
    - - Permitem ao gerente de projeto:
        
        Avaliar o estado do projeto
        
        Rastrear os riscos
        
        Agir de forma preventiva
        
        Ajustar o fluxo das tarefas
        
        Aferir a qualidade do resultado
      - Usadas para fins táticos
        
        Minimizar cronograma para evitar atrasos.
        
        Avaliar a qualidade do produto de forma contínua.
      - Na medida em que a qualidade melhora, os defeitos são minimizados, o retrabalho diminui e a duração do projeto diminui.
  - - - Métricas de software orientadas a tamanho são criadas normalizando-se as medidas de qualidade e/ou produtividade considerando o tamanho do software que foi produzido.
      - Se uma organização de software mantém registros simples, pode ser criada uma tabela de medidas orientadas a tamanho.
      - Para desenvolver métricas que possam ser assimiladas às de outros projetos, pode-se escolher número de linhas de código como um valor de normalização.
      - A partir dos dados rudimentares contidos na tabela, pode ser desenvolvido um conjunto de métricas simples orientadas a tamanho para cada projeto
        
        Erros por KLOC (mil linhas de código)
        
        Defeitos por KLOC
        
        $ por KLOC
        
        Páginas de documentação por KLOC
    - - Métricas de software orientadas a função usam uma medida da funcionalidade fornecida pela aplicação como um valor de normalização.
      - A métrica orientada a função mais amplamente usada é a de Pontos por Função (FP).
      - O cálculo de pontos de função é baseado nas características de domínio de informação e complexidade do software.
      - A seleção entre linhas de código e pontos de função depende da linguagem de programação que é usada para implrementar o software.
      - Muitos estudos já tentaram relacionar FP e LOC e derivar métricas de produtividade.
      - O desempenho dos indivíduos não deve ser avaliado usando essas métricas, pois muitos fatores influenciam a produtividade, gerando comparações que podem ser mal interpretadas.
    - - LOC ou FP não fornecem granularidade suficiente para ajustes no esforço e cronograma de projetos OO.
      - Número de scripts de cenário:
        
        Está diretamente relacionado ao tamanho da aplicação e ao número de casos de testes para exercitar o sistema.
      - Número de classes-chave (CC), classes de apoio (CA) e número médio de CA para cada CC
        
        É uma indicação da quantidade de esforço necessário para desenvolver o software e do potencial de reutilização do código
      - Número de subsistemas
        
        Uma vez identificados os subsistemas, é mais fácil elaborar um cronograma no qual eles são divididos entre o pessoal de prrojeto
    - - Possui similaridades com pontos de função, ao independer da linguagem de programação
      - Ainda não existe uma média padronizada do que é um caso de uso.
      - Portanto, sua aplicação como medida de normalização é suspeita. Ex.: esforço gasto por cada caso de uso
    - - Grau de personalização para WebApp
        
        C = Ndp / [Ndp + Nsp]
        Nsp: número de páginas Web estáticas
        Ndp: número de páginas Web dinâmicas
        
        Varia de 0 a 1, sendo que o nível de personalização do WebApp se torna um aspecto técnico significativo com C maior.
      - Número de páginas estáticas
      - Número de páginas dinâmicas
      - Número de links de páginas internos
      - Número de objetos persistentes
      - Número de sistemas externos interfaceados
      - Número de objetos de conteúdo estático
      - Número de objetos de conteúdo dinâmico
      - Número de funções executáveis
    - - Medidas diretas. Ex.: o comprimento de um parafuso
      - Medidas indiretas. Ex.:a qualidade dos parafusos produzidos, medida contando os rejeitos.
    - - Medidas diretas são mais fáceis de serem medidas. Ex.: esforço, custo, LOC, erros, defeitos,
      - Medidas indiretas são mais difíceis de serem medidas. Ex.: funcionalidade, qualidade, complexidade, eficiência
  - - - Corretude
        
        Grau com o qual o software executa sua função
      - Manutenibilidade
        
        Facilidade com a qual um programa pode ser corrigido se for encontrado um erro, adaptado se o ambiente mudar, ou melhorado se o cliente desejar alteração de requisitos
      - Integridade
        
        habilidade de um sistema em resistir aos ataques à sua segurança
      - Usabilidade
        
        Quantificação da facilidade de uso de um software
    - - Traz visibilidade tanto para o processo quanto para o projeto
      - DRE = E / E + D
    - - Erros acontecem durante o desenvolvimento, quando um desenvolvedor não corrige um problema que criou.
      - Defeito acontece quando um erro de um desenvolvedor gera problemas para outro
      - Falha contece no teste do software executável, caso os defeitos não tenham sido corrigidos
      - Bugs são falhas que não foram identificadas e/ou corrigidas antes do software ser entregue ao cliente
  - - - Por uma questão cultural, as pessoas não gostam de medir, pois nunca mediram e afirmam não ter tempo/motivação
      - Uma vez iniciada deve-se esperar pelo menos 3 anos para se conhecer as tendências organizacionais
      - Os benefícios das medidas são tão atraentes que compensam o trabalho duro
    - - O estabelecimento de uma linha base (baseline) para métricas permite que projetos passados sejam usados como referência para projetos correntes ou futuros.
    - - Deve haver coleta de dados em todas as fases de um software. No processo de engenharia de software, projeto de software e artefatos de software.
      - Com as medidas em mãos pode-se calcular as métricas.
      - Ao avaliar as métricas obtêm-se os indicadores
- - - - É uma representação que permite ao engenheiro de software
        
        Analisar a efetividade do projeto quanto à aderência a seus requisitos
        
        Considerar alternativas arquiteturais em um estágio tal que mudanças no projeto sejam relativamente fáceis de serem implementadas
        
        Reduzir os riscos associados à construção do software
  - - - O software cliente acessa um repositório central, que pode ser passivo (acesso independente de quaisquer alterações nos dados ou das ações de outros clientes)
      - Uma variação dessa abordagem transforma o repositório em um quadro de avisos que envia notificações ao software-cliente quando os dados de seu interesse mudam.
    - - Programa principal e subprograma
      - Chamadas a procedimentos remotos
      - Características hierárquicas
    - - Não apresenta uma estrutura comum, pois depende da associação de suas diversas classes
      - Os componentes de um sistema encapsulam dados e as operações que devem ser aplicadas para manipular os dados
      - A comunicação entre as classes é feita por meio de troca de mensagens
    - - Um conjunto de componentes que realiza uma função exigida por um sistema. Ex.: um banco de dados.
      - Um conjunto de conectores que habilitam a comunicação, coordenação e cooperação entre os componentes
      - Restrições que definem como os componentes podem ser integrados para formar o sistema
      - Modelos semânticos que permitem compreender as propriedades gerais de um sistema por meio da análise das propriedades conhecidas de suas partes consultantes.
    - - Cada filtro trabalha de forma independente aos componentes que se encontram acima e abaixo deles, é projetado para esperar a entrada de dados de determinada forma e produzir saída de dados (para o filtro seguinte) da forma especificada
      - Um dado filtro não precisa conhecer o funcionamento interno dos filtros vizinhos
      - Tubos e filtros
      - Características de comandos
    - - São definidas várias camadas diferentes, cada uma realizando operações que progressivamente se tornam mais próximas do conjunto de instruções de máquina
      - Na camada mais externa, os componentes atendem operações de interface do usuário
      - Na camada mais interna, os componentes realizam a interface com o sistema operacional
      - As camadas intermediárias fornecem serviços utilitários e funções de software de aplicação
      - Características de Sistema Operacional
  - - - Quando o projeto da arquitetura se inicia, o software deve ser colocado no contexto.
      - Deve-se definir as entidades externas com as quais o software interage e a natureza da interação (outros sistemas, dispositivos, pessoas)
      - Essas informações em geral podem ser obtidas do modelo de requisitos e todas as demais coletadas durante a engenharia de requisitos
      - Uma vez que o contexto é modelado e todas as interfaces de software externas tenham sido descritas, pode-se identificar um conjunto de arquétipos arquiteturais
      - Estrutura
        
        Sistemas superiores
        
        Sistemas que usam o sistema-fonte como parte de algum esquema de processamento de mais alto nível
        
        Sistemas subordinados
        
        São utilizados pelo sistema-alvo e fornecem dados ou processamento necessários para completar a funcionalidade do sistema-alvo
        
        Sistemas pares
        
        Interagem em uma base par-a-par, com as informações sendo produzidas ou consumidas pelos pares e sistema-alvo
        
        Atores
        
        Entidades que interagem com o sistema-alvo através da produção ou consumo de informações
    - - Arquétipo é uma classe ou padrão que representa uma abstração central crítica para o projeto de uma arquitetura para o sistema-alvo.
      - Em geral, é necessário um conjunto relativamente pequeno de arquétipos para projetar até mesmo sistemas relativamentes complexos.
      - A arquitetura do sistema é composta desses arquétipos, que são elementos arquiteturais estáveis cuja instanciação pode variar de acordo com o comportamento do sistema
    - - À medida que a arquitetura de software é refinada em componentes, a estrutura do sistema começa a emergir
      - As classes de análise representam entidades no domínio de aplicação que deve ser tratado na arquitetura de software. Portanto, o domínio de aplicação é uma fonte para a derivação e o refinamento de componentes.
      - Outra fonte é o domínio da infraestrutura. A arquitetura deve acomodar muitos componentes de infraestrutura que possibilitem componentes de aplicação, mas que não tenham nenhuma ligação de atividade com o domínio de aplicação
    - - O projeto da arquitetura até este ponto ainda é relativamente de alto nível.
      - O contexto do sistema foi representado, arquétipos que indicam as abstrações cruciais foram definidos, a estrutura global do sistema está evidente e os principais componentes de software foram identificados.
      - Entretanto, um maior refinamento (recorde-se que todo projeto é iterativo) ainda é necessário.
      - Para tanto, é desenvolvida uma instância real da arquitetura.
      - Deseja-se aplicar a arquitetura a um problema específico com o fim de demonstrar que a estrutura e os componentes são apropriados.
- - - - Entre os componentes de um software
      - Entre o software e outros produtores e consumidores de informação que não sejam humanos
      - Entre o ser humano e o computador (IU)
        
        Precisa ser
        
        Fácil de usar
        
        Fácil de entender
        
        Fácil de aprender
        
        Não frustrante
        
        Envolve
        
        Conhecimento das pessoas
        
        Conhecimento de tecnologias
        
        Erros típicos
        
        Falta de consistência
        
        Memorização muito elevada
        
        Sem guia/ajuda
        
        Sem sensibilidade a conteúdo
        
        Resposta pobre
        
        Arcaico/não amigável
    - - O estudo das versões do Windows mostra que qualquer empresa, por maior e mais poderosa que seja, pode perder sua hegemonia se continuar insistindo em não obedecer as regras de ouro para a IU
  - - - Defina modelos de interação de forma que não force o usuário a tomar ações desnecessárias ou não desejadas
      - Proporcione interação flexível (teclado, mouse, atalhos, voz, toque)
      - Permita que a interação com o usuário possa ser interrompida e desfeita
      - Projete a interação diretamente com objetos que aparecem na tela (ampliar, reduzir, deformar, girar)
      - Simplifique a interação à medida que os níveis de competência progridem e permita que a interação seja personalizada (macros, atalhos de teclado)
      - Esconda detalhes técnicos dos usuários casuais (ter que digitar um comando do SO)
    - - Libere a informação de modo progressivo
      - Reduza a demanda de memória recente
      - Estabeleça defaults significativos
      - Defina atalhos que sejam intuitivos
      - O leiaute visual da IU deve ser baseado em metáforas do mundo real (ícone do carrinho de compras)
    - - Permita ao usuário inserir a tarefa atual em um contexto significativo
      - Mantenha a consistência ao longo de uma família de aplicações
      - Se modelos interativos anteriores tiverem criado expectativa nos usuários, não faça alterações a menos que haja uma forte razão para isto
  - - - Modelo de usuário
        
        Um perfil de todos os usuários finais do sistema
      - Modelo de projeto
        
        A realização do projeto do modelo de usuário
      - Modelo mental (percepção do sistema)
        
        Imagem mental do usuário de como é a IU
      - Modelo de implementação
        
        A aparência da IU combinada com a informação de suporte, descrevendo sua sintaxe e semântica
      - A diferença entre o modelo de implementação e o modelo mental é chamada de Gap Mental
- - - - Planejamento do teste
      - Projeto dos casos de teste
      - Execução dos testes
      - Coleta e avaliação dos dados
    - - Conduzir revisões formais antes dos testes no código
      - Começar pelo componente e seguir em direção ao sistema
      - Usar técnicas diferentes dependendo do momento
      - Em pequenos projetos o próprio desenvolvedor realiza o teste
      - Em projetos maiores, um time independente deve ser utilizado
      - Definir um processo de depuração
      - Pode haver um conflito de interesses entre desenvolvedores e testadores independentes, pois um é orientado a entrega e pode fazer testes com menos rigidez, enquanto outro é orientado pela qualidade e testará para quebrar o software
    - - Verificação
        
        Garante que o software implemente uma função específica corretamente.
      - Validação
        
        Garante que o software atende aos requisitos do cliente
    - - Software convencional
        
        O módulo (componente) é o foco inicial, seguindo ao teste de integração
      - Software OO
        
        O teste de unidade passa a ser uma classe, englobando atributos e operações, seguindo à comunicação e colaboração com outras classes
    - - Engenharia de sistemas
      - Teste de sistema
      - Requisitos
      - Teste de validação
      - Projeto
      - Teste de integração
      - Código
      - Teste de unidade
      - No processo de Software, o deslocamento é de cima para baixo, diminuindo o nível de abstração
      - No processo de teste de Software, o deslocamento é de baixo para cima, aumentando o escopo
    - - Executar os testes somente com o sistema completo, visando encontrar erros
        
        Essa abordagem, embora atraente, simplesmente não funciona e resulta em um software defeituoso que desagrada todos os investidores
      - Executar testes diariamente, sempre que uma parte do sistema for construida
        
        Embora menos atraente, pode ser muito eficaz. Infelizmente, alguns desenvolvedores hesitam em usar esta abordagem.
      - Uma preferida pela maioria das equipes de software está entre os dois extremos. Ela assume uma visão incremental do teste, começando com o teste das unidades individuais de programa, passando para os testes destinados a facilitar a integração de unidades e culminando com testes que usam o sistema concluído
  - - - Focaliza o esforço de verificação no componente ou módulo de software
      - A complexidade/abrangência são limitadas pelo escopo estabelecido para o teste de unidade, podendo ser projetado antes de começar a codificação ou depois que o código-fonte tiver sido gerado.
      - Enfoca a lógica interna e as estruturas de dados dentro dos limites de um componente
      - Esse tipo de teste pode ser conduzido em paralelo para diversos componentes, sendo um auxiliar para a etapa de codificação.
      - O engenheiro de software cria casos de teste que são aplicados ao módulo e geram resultados para análise
      - O exame das informações de projeto fornece
        instruções para estabelecer casos de testes
        que provavelmente mostrarão os erros em
        cada uma das categorias descritas ao lado.
      - Cada caso de teste deverá ser acoplado a
        um conjunto de resultados esperados.
      - Ambiente de teste unitário
        
        Devido ao fato de um componente não ser um programa independente (stand-alone), deve ser desenvolvido um pseudocontrolador (driver) e/ou um pseudocontrolado (stub) para cada teste de unidade.
        
        Um pseudocontrolador atua como um programa principal que aceita dados do caso de teste, passa esses dados para o componente (a ser testado), e imprime resultados relevantes. Substitui módulos subordinados ao componente a ser testado.
        
        Um pseudocontrolado, usa a interface dos módulos subordinados, podendo fazer manipulação de dados mínima, fornecer verificação de entrada e retornar o controle para o módulo que está sendo testado.
    - - É uma técnica sistemática para construir a arquitetura de software ao mesmo tempo que conduz testes para descobrir erros associados com as interfaces.
      - O objetivo é construir uma estrutura de programa determinada pelo projeto a partir de componentes testados em unidade.
      - Abordagem big-bang
        
        Estratégia de construção não incremental
        
        tudo é integrado de uma só vez
        
        Deve sempre ser evitada, pois dificulta o isolamento de causas
      - Estratégia top-down
        
        Os módulos do topo são testados com stubs
        
        Os stubs são substituídos, um de cada vez, primeiro em profundidade
        
        Na medida em que novos módulos são integrados, alguns subconjuntos de testes são reaplicados
      - Estratégia bottom-up
        
        Drivers são substituídos, um de cada vez, abordagem primeiro em profundidade
        
        Módulos são agrupados em builds e integrados
      - Estratégia sanduíche
        
        Top-down + bottom-up
    - - Teste automatizado que roda periodicamente ou sob demanda