Instituto Tecnológico de Aeronáutica
CE-230 Qualidade, Confiabilidade e Segurança
(Safety) de Software
Relatório do Segundo Sprint
Qualidade, Confiabilidade e Segurança do
Dispositivo de Controle de Fraudes – DCF
Milton Luiz Abrunhosa
Prof. Dr. Adilson Marques da Cunha
Introdução
“Não se pode gerenciar o que não se pode medir” Tom de Marco
Motivação
Vivenciar a evolução de um projeto utilizando metodologia ágil e desenvolver a habilidade em para criar um Plano de Garantia que seja referência única sobre a qualidade de Projeto. Acredito que esta atividade será de grande valia profissional, pois me dará bagagem para estabelecer um padrão entre os desenvolvedores que tenho a oportunidade de cooperar e colaborar dentro da Empresa.
Objetivo
Este trabalho tem a intenção de aferir quanto à qualidade, confiabilidade e segurança do segundo sprint de desenvolvimento do subproduto do DCF – Dispositivo de Controle de Fraude desenvolvido pelos alunos da CE-235/CES-63, a fim de elevar o nível de maturidade do produto em desenvolvimento.
Descrição dos Procedimentos Utilizados
Segundo Sprint
Para acompanhamento dos Primeiro e Segundo Sprint de desenvolvimento do suproduto DCF, o Scrum Master manteve um dashboard conforme Erro! Fonte de
referência não encontrada. e Erro! Fonte de referência não encontrada., que nos
deu visão sobre as etapas de desenvolvimento e evolução do subproduto DCF.
Conforme relatado no relatório anterior, a grande dificuldade encontrada pelo grupo foi na abstração da realidade quanto à necessidade de um dispositivo de tempo real para o desenvolvimento de software embarcado. Por característica da necessidade do subproduto DCF, o mesmo foi criado para ser um serviço de análises de georreferenciamento, de padrão de consumo e dispositivo em transações financeiras por cartão de crédito.
O desenvolvimento teve forte tendência em ser mais para uma solução em tecnologia da informação do que propriamente para um software para ser embarcado em um Arduino. Assim, o desenvolvimento do modelo DCF foi realizado utilizando o IBM Rational Rose RealTime (RRRT), e uma segunda frente de desenvolvimento foi feito baseado em Python, para desenvolvimento da conexão com Banco e análise de transações (No Anexo G pode ser visualizado os códigos em linguagem natural).
Durante o Primeiro Sprint foi identificado que os alunos da CE-235/CES-63, motivados pela necessidade de elaborar uma solução em Tecnologia da Informação, deixaram em segundo plano o desenvolvimento do modelo RRRT.
Como o papel do grupo da CE-230 era a responsabilidade em aferir qualidade, confiabilidade e segurança em um modelo, nós assumimos o risco e criamos um modelo do DCF no RTTT. Este modelo em seguida foi apresentado e adotado pelos alunos da CE-235/CES-63 através do ScrumMaster.
Foi desenvolvido o modelo Erro! Fonte de referência não encontrada.Erro!
Fonte de referência não encontrada.para criar um software capaz de ser embarcado
no Arduíno dentro do DCF para controlar a comunicação com o DCA. O Erro! Fonte
de referência não encontrada. demonstra o modelo conceitual do servidor. No Anexo
H pode-se visualizar um relatório de análise do DCF. Este relatório foi montando com a intenção de demonstrar ao administrador do serviço uma visão sobre as detecções de fraudes.
Neste segundo sprint foram criados massas de dados para simular condições normais de uso em condições de fraude. O modelo conceitual do Banco de Dados pode ser visto no Erro! Fonte de referência não encontrada..
O Product Backlog completo do subproduto DCF pode ser acessado a partir deste link. Este Product Backlog não sofreu alterações significativas entre o primeiro e segundo sprint.
Para testar o dispositivo DCF, os alunos da CE-237 criaram um plano de teste e o mesmo pode ser acessado neste link.
Erro! Fonte de referência não encontrada.
Harness Test
O Objetivo foi de simular a execução do modelo DCF no Rational Rose Real Time e sem seguida, de realizar um teste RQA - HARDNESS com o propósito de aferir qualidade, confiabilidade e segurança entre a interação do DCA com o DCF.
Para viabilizar o teste foi criando um projeto no ambiente do RRRT com duas capsulas representando o DCA (Dispositivo de controle de Acesso) e o DCF (Dispositivo de controle de Fraudes) conforme Erro! Fonte de referência não encontrada..
As capsulas DCA e DCF foram conectadas utilizando um protocolo denominado como token, que tem a responsabilidade de transportar a transação.
A estrutura da capsula DCA (Erro! Fonte de referência não encontrada.) tem o objetivo de receber uma nova transação, realizar a autenticação e enviar a transação para o DCF.
A estrutura da capsula DCF tem o objetivo de receber a transação do DCA e validar a transação com o padrão de consumo do usuário, depois validar a transação utilizando analises GEO Referenciadas e finalmente, devolver para a transação DCA com status de aprovada ou reprovada, com todas as interações devidamente autenticadas (Erro! Fonte de referência não encontrada.).
No Erro! Fonte de referência não encontrada.Erro! Fonte de referência não
encontrada., Anexo G e Anexo H podem ser visualizados o diagrama de sequencias, a
execução do diagrama de estados e a análise do Trace.
A execução do programa resultou no log do Erro! Fonte de referência não
encontrada., demonstrado todas as sequencias de execução da máquina de estados.
O Hardness Test pode ser visualizado no Erro! Fonte de referência não
encontrada. e no Erro! Fonte de referência não encontrada.. Em seguida, no Erro! Fonte de referência não encontrada. é apresentado a sequencia Happy test, que seria
uma simulação de uma sequencia considerada ideal. O resultado deste teste pode ser visualizado no Erro! Fonte de referência não encontrada..
O modelo elaborado pela Rational Rose Real Time permitiu a geração de códigos C++ vistos no screenshot do Erro! Fonte de referência não encontrada.. Os arquivos do modelo assim como os códigos gerados pelo RRRT podem ser acessados neste link.
Plano de Garantia da Qualidade
O Plano de Garantia da Qualidade passou por uma revisão para melhor definição sobre auditoria. Conforme definido no Plano de Garantia de Qualidade, os artefatos de Plano de Desenvolvimento de Software, Plano de Teste, Termo de confidencialidade, Modelo UML e um Road Map foram utilizados para a entrega final do subproduto DCF.
Por não haver declaração formal dos critérios de aceitação do subproduto DCF, o Plano de Garantia da Qualidade define por padrão os seguintes testes de verificação padrão:
Usabilidade: Através do teste do modelo do RTTT pode ser verificado o comportamento do DCF na analise de fraude. Pode se simular Happy Paths e condições de Fraudes através de um gerador randômico.
Regressão: Por ser desenvolvimento de um protótipo, não foram aplicadas testes de regressão.
Integração: Evidenciado no teste do modelo SETRAIF que a integração entre o DCF como DCA ocorreu de forma satisfatória, permitindo que o SETRAIF fizesse a verificação de fraude fosse simulada.
Unitário: O RQA-RT gerou automaticamente testes unitários e de integração, permitindo que os resultados pudessem analisados diretamente no programa. Aceitação: Foi elaborada em conjunto com os outros subprodutos uma estória
completa de uma transação de compra, podendo assim simular ao cliente o comportamento do Setraif.
Métricas de Software
O objetivo das métricas de software, de acordo com o seu conceito original, é a identificação e medição dos principais parâmetros que afetam o desenvolvimento de
software (Mills, 1998).
Uma métrica, segundo definição da ISO 9126 (ISO/IEC9126-1, 2001), é a composição de procedimentos para medição e escalas de medidas. Os fatores/características da ISO 9126 não necessariamente se prestam para medidas diretas. Fornecem, sim, uma base valiosa para medidas indiretas e uma excelente lista de verificações para avaliar a qualidade de um sistema.
Métricas que facilitam o desenvolvimento de modelos capazes de estimar o processo e/ou os parâmetros do software são consideradas boas métricas, sendo ideal terem as seguintes características (Mills, 1998):
Simplicidade: o significado da métrica para a avaliação e claro; Objetividade;
Fácil obtenção: o custo de obtenção da métrica não é excessivo; Validade: a métrica efetivamente mede o que se propõe a medir;
Robustez: a métrica não sofre grandes desvios com pequenas mudanças no processo e no software;
Linearidade de escala: há formas de mapeamento para o entendimento do comportamento das entidades através da manipulação dos números obtidos (Fenton e Peeger, 1998).
Embora o DCF tenha um viés em tecnologia da informação, o desenvolvimento do modelo foi através do RRRT. Na primeira versão não era possível executar o Harness Test, então este modelo foi readequado e as métricas foram definidas conforme Erro!
Fonte de referência não encontrada..
Métricas Estáticas
A medida estatística do código fonte é de extrema importância no planejamento do teste ou na gerência do projeto. O IBM Rational Test RealTime fornece uma exibição detalhada dos dados e estatísticas da complexidade do código fonte.
Gráfico com as medidas obtidas para o DCF.cpp
Métricas de Halstead
É um conjunto de métricas baseadas na teoria da informação, consideradas as primeiras métricas com fundamentação teórica comum, também chamada de Software Science (Halstead, 1972, 1977). Essas métricas se aplicam a vários aspectos do
software, diferentemente da maior parte das métricas, que tratam um aspecto particular,
e também são usadas para avaliar o esforço global de desenvolvimento do software. O Vocabulário (n), Comprimento (N) e Volume (V) são métricas que se aplicam especificamente ao software final. Também foram especificadas fórmulas para calcular o esforço total (E) e tempo de desenvolvimento (T) de software.
Vocabulário do Programa
O software pode ser visualizado com uma seqüência de símbolos (tokens), sendo cada símbolo classificado em operadores ou operandos. Assim, o vocabulário do programa (n) é definido como:
n = n1 + n2
onde n1 é o número de operadores únicos e n2 e o número de operandos únicos do programa.
Gráfico da métrica de vocabulário do subproduto DCF
Comprimento do Programa
Enquanto o vocabulário é a soma dos símbolos (tokens) diferentes, o comprimento do programa (N) é a soma do total de operadores e operandos, sendo dado como:
N = N1 + N2
onde N1 é o número total de operadores e N2 e o número total de operandos do programa. Porém, a distinção entre operadores e operandos não é muito clara (Halstead, 1977). Então o valor N pode ser estimado como:
N´ = n1 * log (n1) + n2 * log (n2)
Sendo N uma medida que pode ser observada ao final do desenvolvimento do código, diferentemente de N´ que pode ser calculada em função dos atuais ou estimados valores de n1 e n2. Estudos empíricos demonstram a validade da equação mostrada (Elshoff, 1976; Halstead, 1977). Outros estudos relacionaram N e N´ com outras métricas, como complexidade (Potier et al., 1982) e número de erros (Elshoff, 1976; Halstead, 1977; Shen et al., 1985; Levitin, 1986; Li e Cheung, 1987). É defendido que a métrica de comprimento é mais objetiva e eficiente que o LOC (Lassez et al., 1981).
Gráfico da métrica de comprimento do subproduto DCF
Volume do Programa
O volume de um programa, medido em bits, é dado em função do seu comprimento e do seu vocabulário:
V = N * log (n).
Determinar o volume não é difícil, pois não envolve análise semântica. Porém, a soma do volume dos módulos de um programa é diferente em relação a soma total do volume do software, devido a variação do vocabulário. Há análises sobre a abrangência da medida do volume do software, destacando a independência em relação à linguagem de programação utilizada (Shen, Conte e Dunsmore, 1983). Foram apresentadas evidências empíricas de que as métricas de comprimento e de volume de Halstead estão linearmente relacionadas com a LOC (Li e Cheung, 1987; Christensen, Fitsos e Smith, 1981).
Gráfico da métrica de volume do subproduto DCF
Métricas de Complexidade de Software
Assim como as métricas de dimensão de software, as métricas de complexidade foram pensadas de acordo com os modelos tradicionais de desenvolvimento e podem ser computadas no início do ciclo de desenvolvimento de software, para o maior sucesso na gerência do processo de software.
Complexidade Ciclomática (v(G))
Parte do princípio que a complexidade depende do número de condições (caminhos), correspondendo ao número máximo de percursos linearmente independentes em um software. A proposta é que se possa medir a complexidade do programa, assim orientando o desenvolvimento e os testes do software (McCabe, 1976). Essa métrica pode ser representada através de um grafo de fluxo de controle, onde os nós representam uma ou mais instruções seqüenciais e os arcos orientados indicam o sentido do fluxo de controle entre varias instruções. A complexidade ciclomática de um determinado grafo pode ser calculada através de uma formula da teoria dos grafos:
v(G) = e - n + 2
onde e é o numero de arestas e n é o número de nós do grafo.
Um estudo concluiu que a produtividade diminui de forma não linear proporcionalmente ao aumento da densidade dos pontos condicionais (Ganey, 1979). A complexidade ciclomática também foi relacionada com os esforços de depuração e manutenção, podendo ser utilizada para estimar custos a partir do projeto detalhado dos módulos (Curtis, Sheppard e Milliman, 1979; Woodfield, Shen e Dunsmore, 1981; Harrison et al., 1982).
Surgiram propostas de extensões e alterações no calculo dessa métrica para melhorar a sua validade (Myers, 1977; Stetter, 1984). Myers observou que complexidade ciclomática mede a complexidade do software, mas não consegue diferenciar a complexidade de alguns casos simples, em especial que envolvam uma única condição. Para melhorar a fórmula original, foi sugerido:
v(G)' = [l : u]
onde l e u são limites inferiores e superiores, respectivamente, para a complexidade, sendo mais satisfatórios para os casos verificados por Myers. Por outro lado, Stetter propôs que o grafo fosse expandido para incluir declarações e referências de dados, mostrando uma complexidade mais completa. Nesse grafo do fluxo do programa (H), geralmente, tem múltiplos nós de entradas e saídas. Assim, as irregularidades verificadas por Myers são eliminadas por uma função f(h).
Uma correlação entre a complexidade ciclomática e as métricas de Halstead foi apresentada em (Henry, Kafura e Harris, 1981). O interesse na métrica de complexidade ciclomática levou a sua normalização (McCabe, 1982). Posteriormente, McCabe definiu outras cinco métricas: complexidade da unidade real, complexidade essencial, complexidade do projeto de módulos, complexidade total do projeto e complexidade de integração (McCabe e Butler, 1989). Essas métricas foram utilizadas para identificar e minimizar a complexidade em códigos não estruturados, decidindo sobre o numero de testes necessários para uma cobertura total das possíveis execuções, eliminando a redundância e restringindo a complexidade de módulos produzidos a um nível aceitável (Mannino, Stoddard e Sudduth, 1990).
Análise de Sensibilidade
Para executar a análise de sensibilidade, utilizou-se o software Source Monitor, que permite gerar analises de código fonte escritos em C, C++, C#, VB.NET, Java, Delphi, Visual Basic ou HTML. Ele permite a determinação de métricas como: linhas de código, porcentagem de comentários, porcentagem de ramificação, complexidade, profundidade, métodos, funções, etc. A partir destas métricas o software propicia a geração do gráfico de Kiviat, executando um comparativo com valores pré-determinados permitindo uma avaliação do código.
Métricas do Código do DCF
Apesar do Source Monitor gerar uma tabela com várias outras métricas, nos gráficos de Kiviat gerados constam apenas as seguintes métricas, como ilustra a figura:
Linhas de Código (Statements);
Percentagem de Comentários (% Comments); Complexidade Máxima (Max Complexity); Complexidade Média (Avg Complexity); Profundidade Máxima (Max Depth); Profundidade Média (Avg Depth).
Conclusão
As facilidades de análise estática do IBM Rational Test RealTime permite a medida da complexidade do código fonte e ainda checar a aderência as orientações de codificação. Estas ferramentas são capazes de analizar o código fonte sem a necessidade de compilação ou execução da aplicação.
Qualidade é uma característica que, nos modelos tradicionais de desenvolvimento de software, pode ser medida em cada fase do ciclo de desenvolvimento de software (Cerino, 1986), mas não foram abordadas métricas específicas do processo de desenvolvimento, pois o IBM Rational Test RealTime não as disponibiliza.
Entretanto alguns outros fatores podem auxiliar na aplicação e/ou avaliação das métricas para garantia da qualidade do software:
Iniciar no início do processo de desenvolvimento; Considerar como parte do processo de desenvolvimento; Começar pequeno;
Selecionar um conjunto coerente de métricas; Definir detalhes das métricas;
Fornecer informações corretas, para as pessoas certas; Agregar valor, ao invés de apenas gerar dados; Incentivar a equipe;
Educação e treinamento;
