O documento apresenta o currículo de Ricardo Terra, incluindo sua formação acadêmica e experiência profissional. Ele também fornece uma introdução sobre análise estática de código, descrevendo seus objetivos, benefícios e como ela se compara a outras técnicas de verificação e validação de software.
2016: Introdução à Mineração de Dados: Conceitos Básicos, Algoritmos e Aplica...Leandro de Castro
Conjunto de slides desenvolvido como material de apoio disponível para uso por professores e alunos da disciplina Mineração de Dados, assim como demais interessados no tema. Apresenta de forma sucinta o conteúdo do livro e os principais conceitos da área.
Seminário sobre Qualidade de Software e modelos de maturidade apresentado no primeiro semestre de 2012 na disciplina de Engenharia de Software no programa de pós-graduação do Departamento de Computação da Universidade Federal de São Carlos.
Apresentação sobre qualidade de software na disciplina de Engenharia de Software no Mestrado Acadêmico em Ciência da Computação em parceria com Bruno Neves.
2016: Introdução à Mineração de Dados: Conceitos Básicos, Algoritmos e Aplica...Leandro de Castro
Conjunto de slides desenvolvido como material de apoio disponível para uso por professores e alunos da disciplina Mineração de Dados, assim como demais interessados no tema. Apresenta de forma sucinta o conteúdo do livro e os principais conceitos da área.
Seminário sobre Qualidade de Software e modelos de maturidade apresentado no primeiro semestre de 2012 na disciplina de Engenharia de Software no programa de pós-graduação do Departamento de Computação da Universidade Federal de São Carlos.
Apresentação sobre qualidade de software na disciplina de Engenharia de Software no Mestrado Acadêmico em Ciência da Computação em parceria com Bruno Neves.
Las Pruebas de Software son todavía una de las áreas más desatendidas del desarrollo y espliegue de los productos de software. Las Pruebas de Software son predominantemente vistas como una actividad periférica, casi una formalidad, antes del espliegue del software. Un cambio de actitud y un buen programa de estudios como fundamento hacia las Pruebas de Software pueden reducir tremendamente los problemas normalmente asociados con el lanzamiento del nuevo software y minimizar el riesgo implicado. El programa de estudio del ISTQB (International Software Testing Qualifications Board) Probador Certificado (Certified Tester) ofrece el mejor
entrenamiento estandarizado del mundo para los probadores de software.
Este libro le proporcionará el conocimiento esencial para ser un profesional en Pruebas, que incluye:
Fundamentos de Pruebas
Pruebas a través del Ciclo de Vida de Software
Técnicas Estáticas
Técnicas de Diseño de Pruebas
Gestión de Pruebas
Soporte de las Herramientas de Pruebas
Adquisición de Herramientas y Software en General en una Organización
Más de 200 preguntas de examen de muestra con soluciones
Ejercicios prácticos y soluciones por cada tema cubierto
Caso real, resuelto, como ejemplo a lo largo de los temas
Dos exámenes de simulación del examen real
Estándares de Pruebas
Excelente Bibliografía
Cabe señalar que este libro no es sólo para los probadores sino también para quienes están encargados de la adquisición de software en general, gerentes de tecnología, gerentes del Aseguramiento de la Calidad/Control de la Calidad (QA/QC), gerentes de sistemas, jefes de proyectos de software, analistas, arquitectos, desarrolladores, estudiantes y profesores de TI.
Asimismo este libro está diseñado para el autoestudio. El contenido comprende el programa de estudios necesario para aprobar el examen de certificación nivel básico definido por el ISTQB versión 2011 (Syllabus 2011).
Conceitos básicos que fundamentam os estudos sobre SI, Diferentes categorias de ativos existentes em uma empresa, Conceitos de vulnerabilidades e ameaças dos ativos, integridade, confidencialidade e disponibilidade, análise de riscos (AR), etc.
Objetivo
Apresentar os conceitos básicos sobre Qualidade de Software
Abordar a questão da qualidade de software, com ênfase em modelos de qualidade de processo de software.
Slide do hangout sobre Lógica de Programação para Iniciantes, exibido pelo LadyTalks.
Link do vídeo: https://www.youtube.com/watch?v=E-b-Vm7MEkY
Palestrante: Mariana Camargo (mundodama.com.br)
É comum ouvirmos falar sobre qualidade de produtos, serviços e afins. E também sabemos que não é uma realidade distante quando falamos de desenvolvimento de software, pois usufruirmos de processos e metodologias, testes de aceitação, funcionais e stress, todo esse conjunto afim de garantir a qualidade e excelência do que foi ou está sendo desenvolvido.
Las Pruebas de Software son todavía una de las áreas más desatendidas del desarrollo y espliegue de los productos de software. Las Pruebas de Software son predominantemente vistas como una actividad periférica, casi una formalidad, antes del espliegue del software. Un cambio de actitud y un buen programa de estudios como fundamento hacia las Pruebas de Software pueden reducir tremendamente los problemas normalmente asociados con el lanzamiento del nuevo software y minimizar el riesgo implicado. El programa de estudio del ISTQB (International Software Testing Qualifications Board) Probador Certificado (Certified Tester) ofrece el mejor
entrenamiento estandarizado del mundo para los probadores de software.
Este libro le proporcionará el conocimiento esencial para ser un profesional en Pruebas, que incluye:
Fundamentos de Pruebas
Pruebas a través del Ciclo de Vida de Software
Técnicas Estáticas
Técnicas de Diseño de Pruebas
Gestión de Pruebas
Soporte de las Herramientas de Pruebas
Adquisición de Herramientas y Software en General en una Organización
Más de 200 preguntas de examen de muestra con soluciones
Ejercicios prácticos y soluciones por cada tema cubierto
Caso real, resuelto, como ejemplo a lo largo de los temas
Dos exámenes de simulación del examen real
Estándares de Pruebas
Excelente Bibliografía
Cabe señalar que este libro no es sólo para los probadores sino también para quienes están encargados de la adquisición de software en general, gerentes de tecnología, gerentes del Aseguramiento de la Calidad/Control de la Calidad (QA/QC), gerentes de sistemas, jefes de proyectos de software, analistas, arquitectos, desarrolladores, estudiantes y profesores de TI.
Asimismo este libro está diseñado para el autoestudio. El contenido comprende el programa de estudios necesario para aprobar el examen de certificación nivel básico definido por el ISTQB versión 2011 (Syllabus 2011).
Conceitos básicos que fundamentam os estudos sobre SI, Diferentes categorias de ativos existentes em uma empresa, Conceitos de vulnerabilidades e ameaças dos ativos, integridade, confidencialidade e disponibilidade, análise de riscos (AR), etc.
Objetivo
Apresentar os conceitos básicos sobre Qualidade de Software
Abordar a questão da qualidade de software, com ênfase em modelos de qualidade de processo de software.
Slide do hangout sobre Lógica de Programação para Iniciantes, exibido pelo LadyTalks.
Link do vídeo: https://www.youtube.com/watch?v=E-b-Vm7MEkY
Palestrante: Mariana Camargo (mundodama.com.br)
É comum ouvirmos falar sobre qualidade de produtos, serviços e afins. E também sabemos que não é uma realidade distante quando falamos de desenvolvimento de software, pois usufruirmos de processos e metodologias, testes de aceitação, funcionais e stress, todo esse conjunto afim de garantir a qualidade e excelência do que foi ou está sendo desenvolvido.
Importância de Testes Automatizados para Continuous Delivery & DevOpsSamanta Cicilia
O mercado tem exigido cada vez mais rapidez nas entregas dos times de desenvolvimento, para atender as demandas de negócio e manter a competitividade. Para garantir que essas entregas aconteçam no tempo esperado e com qualidade, é muito importante investir em todos os níveis de teste automatizados. Vamos ver quais são esses níveis de teste e alguns exemplos práticos usando Python de testes unitários, integração, funcionais, performance e mutação.
Palestra ministrada no evento Javou! #08, realizado pela comunidade JavaCE, dia 12/11/2016 no Auditório Nadir Papi Saboya, Faculdade Farias Brito, em Fortaleza-CE
OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE DE PROJETOSLuiz Ladeira
Este trabalho descreve a importância do teste de software nas organizações e seus fundamentos. Tal abordagem se justifica na demonstração dos fundamentos básicos do teste de software, para aqueles que desejam aplicar seus fundamentos em projetos de software e os impactos que sua falta pode causar nos negócios das organizações.
Apostila Linguagens Formais e Autômatos (LFA)Ricardo Terra
1 Revisão
- Conjuntos, relações e funções
- Definições Recursivas
- Indução Matemática -
- Linguagens Formais e Autômatos (LFA)
- Lemas, Teoremas, Corolários, etc.
2 Introdução
- Hierarquia de Chomsky
- Conceitos Básicos
3 Linguagens Regulares
- Conjuntos Regulares
- Expressões Regulares
- Gramáticas Regulares
- Autômatos Finitos
- Autômatos Finitos Determinísticos
- Autômatos Finitos Não-Determinísticos
- Autômatos Finitos Não-Determinísticos com Transições-λ
- Autômatos com Saída
- Máquina de Moore
- Máquinas de Mealy
- Algoritmos de Transformação
- Algoritmos
- Transformação AFND-λ para AFD
- Minimização de AFD
- Transformação de ER para AFND-λ
- Propriedades
- Lema do Bombeamento
4 Linguagens Livres de Contexto
- Gramática Livre de Contexto
- Recursividade
- Árvore de Derivação
- Ambiguidade
- Backus-Nahur Form (BNF)
- Formas Normais
- Transformações de Gramática
- Remoção de recursividade no símbolo inicial
- Eliminação de regras λ
- Eliminação de regras de cadeia
- Remoção de símbolos inúteis (TERM e REACH)
- Forma Normal de Chomsky
- Remoção de recursividade à esquerda
- Forma Normal de Greibach
- Autômatos com Pilha
- Variantes
- Critérios de Aceitação
- Algoritmos de Reconhecimento
- Autômato com Pilha como Reconhecedor
- Autômato com Pilha Descendente
- Algoritmo de Cocke-Younger-Kasami (CYK)
- Algoritmo de Early
- Algoritmos
- Transformação de GLCs para APs
- Transformação de APs para GLCs
- Propriedades
5 Linguagens Sensíveis ao Contexto
- Gramática Sensível ao Contexto
- Autômato Linearmente Limitado
- Teoremas
6 Linguagens Irrestritas
- Gramática Irrestrita
- Teoremas
- Máquinas de Turing
- Variantes
- Teoremas
7 Considerações Finais
- Hierarquia de Chomsky
- Tese de Church-Turing
Projeto de articulação curricular:
"aLeR+ o Ambiente - Os animais são nossos amigos" - Seleção de poemas da obra «Bicho em perigo», de Maria Teresa Maia Gonzalez
Slides Lição 9, Central Gospel, As Bodas Do Cordeiro, 1Tr24.pptxLuizHenriquedeAlmeid6
Slideshare Lição 9, Central Gospel, As Bodas Do Cordeiro, 1Tr24, Pr Henrique, EBD NA TV, Revista ano 11, nº 1, Revista Estudo Bíblico Jovens E Adultos, Central Gospel, 2º Trimestre de 2024, Professor, Tema, Os Grandes Temas Do Fim, Comentarista, Pr. Joá Caitano, estudantes, professores, Ervália, MG, Imperatriz, MA, Cajamar, SP, estudos bíblicos, gospel, DEUS, ESPÍRITO SANTO, JESUS CRISTO, Com. Extra Pr. Luiz Henrique, 99-99152-0454, Canal YouTube, Henriquelhas, @PrHenrique
3. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 3Análise Estática de Código
1. Introdução (1/2)
§ Construção de software não é uma tarefa simples
§ pode se tornar bastante complexa
§ Sujeita a diversos tipos de problemas
§ leva à obtenção de um produto diferente daquele que se
esperava
§ Vários fatores são causas desses problemas
§ contudo a maioria deles tem origem no erro humano
4. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 4Análise Estática de Código
1. Introdução (2/2)
§ A construção do software depende principalmente das pessoas
que o constroem
§ por isto, erros acabam surgindo mesmo com a utilização de
métodos e ferramentas de engenharia de software
§ Estes erros podem ser encontrados antes de o software entrar
em produção
§ uma série de atividades, em conjunto conhecidas como
"Verificação e Validação" ou "V&V" possuem esse objetivo
5. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 5Análise Estática de Código
2. Verificação e Validação (1/5)
§ Verificação e validação, segundo Boehm, podem parecer a
mesma coisa, mas não são
§ Verificação – estamos construindo o produto corretamente?
§ o projeto do software atende à sua especificação?
§ Validação – estamos construindo o produto correto?
§ o software realiza exatamente o que o usuário espera
que ele faça?
§ Confiança no software é o objetivo principal do processo de V&V
6. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 6Análise Estática de Código
2. Verificação e Validação (2/5)
§ Segundo Sommerville, existem duas abordagens
complementares para a verificação e validação do sistema:
§ Inspeções de software
§ analisam e verificam representações de sistema como
documentos de requisitos, diagramas e código fonte do
programa
§ revisões de código, análises automatizadas e verificação
formal são técnicas de V&V estáticas
§ Testes de software
§ envolvem executar uma implementação do software com
dados de teste para examinar as saídas e o
comportamento operacional
§ teste é uma técnica de V&V dinâmica
7. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 7Análise Estática de Código
2. Verificação e Validação (3/5)
§ Inspeções de software
§ Revisão de código
§ examinar o programa, em buscas de erros, omissões ou
anomalias, sem executá-lo
§ geralmente dirigidas por checklists de erros e heurísticas
§ Análises automatizadas
§ processo de revisão de código automatizado para alguns
erros e heurísticas
§ Verificação formal
§ verificar a correção dos algoritmos subjacentes a um
sistema com relação a uma certa propriedade ou
especificação formal, utilizando métodos formais
8. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 8Análise Estática de Código
2. Verificação e Validação (4/5)
§ Testes de software
§ Teste de defeitos
§ encontrar inconsistências entre um programa e sua
especificação, isto é, revelar defeitos
§ Teste de validação
§ tem a finalidade de mostrar que o software é o que o
cliente deseja
§ Contudo, conforme Dijkstra, o teste pode mostrar a presença de
erros, mas não demonstrar que não existam erros
remanescentes
9. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 9Análise Estática de Código
2. Verificação e Validação (5/5)
§ As técnicas de inspeções de software podem somente verificar
a correspondência entre um programa e sua especificação
§ Os testes podem verificar a correspondência entre um programa
e sua especificação e:
§ validar se a funcionalidade é a que o seu proprietário
realmente deseja
§ verificar propriedades emergentes como desempenho e
confiabilidade
§ Portanto, inspeções e testes não são abordagens concorrentes,
mas sim, complementares
§ cada uma tem vantagens e desvantagens sobre a outra
§ devem ser usadas em conjunto no processo de V&V
10. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 10Análise Estática de Código
3. Análise Estática de Código (AEC) (1/9)
§ AEC se refere à análise automatizada
§ que é uma das técnicas de inspeção de software no
processo de V&V
§ seu objetivo é reduzir o número de erros de um programa
§ faz isto chamando a atenção para anomalias do programa
§ geralmente erros de programação ou omissões
§ possíveis erros quando o programa fosse executado
§ exemplos comuns de anomalias:
§ bloco catch vazio
§ conexão ou fluxo não encerrado
§ perda de referência nula
§ comparação de objetos com '=='
11. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 11Análise Estática de Código
3. Análise Estática de Código (AEC) (2/9)
§ Verificação estática de código
§ é verificação realizada por uma ferramenta automatizada
(verificador) seguida de uma análise humana sobre os
resultados
§ não é necessário passar informações ao verificador
§ as informações necessárias são dedutíveis do código
fonte ou mesmo do código objeto
§ algumas ferramentas adotam anotações em código para
passar mais informações ao verificador
§ as anomalias encontradas podem não ser defeitos o que
justifica:
§ a análise humana
§ adoção de anotações
12. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 12Análise Estática de Código
3. Análise Estática de Código (AEC) (3/9)
§ Benefícios da utilização de um verificador estático:
1. encontra erros e códigos de risco
2. fornece um retorno objetivo aos programadores para ajudá-los
a reconhecer onde eles foram precisos e onde eles foram
desatentos
3. fornece a um líder de projeto uma oportunidade para estudar o
código, o projeto e a equipe sob uma perspectiva diferente
4. retira certas classes de defeitos, o que possibilita que a equipe
concentre-se mais em outras deficiências do projeto
13. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 13Análise Estática de Código
3.1. AEC: Linhas de Atuação (4/9)
§ Os verificadores estáticos de código podem verificar:
§ regras de estilo
§ erros
§ ambos
14. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 14Análise Estática de Código
3.1. AEC: Linhas de Atuação (5/9)
§ Verificador de regras de estilo (style checker, em inglês)
§ verifica a conformação de um código fonte à sua definição de
estilo de programação, por exemplo:
§ abertura de chaves
§ ordem de declaração
§ javadoc
§ atribuições em subexpressões
§ uso da referência this
§ visibilidade não explicitada
§ difere-se de um programa Beautifier
§ podem ajudar a prevenir certos tipos de erros e a melhorar a
qualidade do software
§ mas violações em regras de estilo não são
necessariamente erros
15. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 15Análise Estática de Código
3.1. AEC: Linhas de Atuação (6/9)
§ Verificador de erro (bug checker, em inglês)
§ uma ferramenta voltada para a detecção automática de erro,
por exemplo:
§ comparação de objetos sem utilizar equals
§ concatenação de strings em laços de repetição
§ fluxo não encerrado
§ com base nas tendências comuns dos desenvolvedores em
atrair defeitos que, em sua maioria, não são visíveis aos
compiladores
§ nem sempre os resultados são defeitos reais
§ mas podem ser vistos como um alerta
16. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 16Análise Estática de Código
3.1. AEC: Linhas de Atuação (7/9)
§ Existe algum problema em se utilizar, em um mesmo projeto, um
verificador de erro e um verificador de regras de estilo?
17. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 17Análise Estática de Código
3.2. AEC: Comparativo com outras técnicas de V&V (8/9)
§ Revisão de código
§ encontrou todos os tipos de defeitos encontrados por um
verificador de erro
§ disparidade em alguns tipos de erros, por exemplo:
§ "variáveis inicializadas, mas não utilizadas"
§ "claúsula if não necessária"
§ mostrou-se mais bem sucedida
§ pois detecta mais tipos de defeitos
§ logo, recomenda-se utilizar uma ferramenta de verificação de
erros antes de revisar o código
18. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 18Análise Estática de Código
3.2. AEC: Comparativo com outras técnicas de V&V (9/9)
§ Teste de software
§ técnica dinâmica, o que já faz com que espere tipos de erros
diferentes
§ defeitos lógicos
§ não houve um mesmo defeito que tenha sido encontrado por
testes e por uma ferramenta de verificação de erros
§ logo, recomenda-se a utilização de ambas as técnicas
19. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 19Análise Estática de Código
4. Ferramentas (1/9)
§ A idéia de ferramentas de análise estática não é nova
§ Em 1970, Stephen Johnson escreveu Lint
§ examinar programas C compilados sem erros
§ verificava erros que tenham escapado ao compilador
§ forçava as regras de tipos e várias restrições de
portabilidade
§ ferramentas descendentes de abordagem diferente, pois:
§ as linguagens atuais apresentam tipagem forte,
portabilidade e não utilizam várias características
propensas a erros
20. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 20Análise Estática de Código
4. Ferramentas: Características (2/9)
§ Existem importantes atributos que uma ferramenta de análise
estática deve ter:
§ Consistência (soundness, em inglês)
§ todo erro real é reportado pela análise
§ Integridade (completeness, em inglês)
§ todo erro reportado é um erro real, isto é, nenhum erro
reportado é um falso positivo
§ Utilidade (usefulness, em inglês)
§ se reporta erros que são relevantes
§ Uma ferramenta de análise estática é consistente, íntegra e útil?
§ não é consistente nem íntegra, assim como as demais
técnicas de V&V
§ ainda assim, esses atributos são cada vez mais visados
21. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 21Análise Estática de Código
4. Ferramentas: Técnicas (3/9)
§ A análise estática em aplicações Java podem atuar sobre o
código fonte e/ou bytecode
§ cada uma das versões tem suas vantagens
§ atuar sobre as duas versões, tirando proveito das vantagens
particulares de cada uma, apresenta-se como a melhor
solução
22. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 22Análise Estática de Código
4. Ferramentas: Principais ferramentas (4/9)
§ As ferramentas em negrito são abordadas nesta palestra:
§ Por que não Jlint, QJ-PRO e ESC/Java2?
23. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 23Análise Estática de Código
4. Ferramentas: Principais ferramentas (5/9)
§ Checkstyle
§ é uma ferramenta voltada à verificação de regras de estilo
§ ordem de declaração
§ padrão de nomenclatura
§ posição da claúsula default em instruções switch
§ atualmente, provê algumas funcionalidades de um
verificador de erro
§ é configurável permitindo customizar as regras por projeto
24. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 24Análise Estática de Código
4. Ferramentas: Principais ferramentas (6/9)
§ FindBugs
§ uma popular ferramenta voltada à verificação de erros
desenvolvida pela University of Maryland
§ provê suporte a mais de 250 padrões de erros
§ valor de retorno ignorado
§ comparação com nulo redundante
§ não utilização de operador de curto-circuito
§ mais de uma centena deles classificados como erros de
correção
§ permite que programadores escrevam seus próprios padrões
de erros
25. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 25Análise Estática de Código
4. Ferramentas: Principais ferramentas (7/9)
§ Klocwork Developer
§ é uma ferramenta voltada exclusivamente à verificação de
erros
§ além de encontrar defeitos
§ também procura por vulnerabilidades de segurança
§ executa métricas e análises arquiteturais
26. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 26Análise Estática de Código
4. Ferramentas: Principais ferramentas (8/9)
§ PMD
§ é uma ferramenta mista
§ começou como um simples verificador de regras de estilo
§ atualmente, já permite que programadores escrevam seus
próprios padrões de erros, assim como ocorre no FindBugs
27. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 27Análise Estática de Código
4. Ferramentas: Principais ferramentas (9/9)
§ Módulos de extensão para a versão mais atual da IDE Eclipse:
28. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 28Análise Estática de Código
5. Avaliação (1/5)
§ As tabelas a seguir apresentam uma breve descrição do defeito
e os resultados da aplicação de cada ferramenta
§ √ indica que alertou
§ - indica que não alertou
29. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 29Análise Estática de Código
5. Avaliação (2/5)
30. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 30Análise Estática de Código
5. Avaliação (3/5)
31. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 31Análise Estática de Código
5. Avaliação (4/5)
§ Falso positivo
§ ocorre quando se adota uma implementação pouco
convencional
§ ocorreu um único falso positivo em um único estudo de caso
§ uma excelente taxa de integridade
§ Se os alertas referem-se a erros reais, mas que os
desenvolvedores não o consideram importante
§ basta a ferramenta prover um filtro de quais problemas
devem ser verificados
§ Contudo, se os alertas referem-se a falso positivos, o problema
está na própria ferramenta
§ uma possível solução seria o uso de anotações
32. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 32Análise Estática de Código
5. Avaliação (5/5)
§ Um único estudo de caso não foi alertado por nenhuma
ferramenta
§ reforça que a ausência de alertas não implica na ausência
de erros
§ A existência de um erro real não alertado e um falso positivo,
somente nos remete ao conceito de que nenhum verificador
estático de código é consistente e íntegro
§ nenhum verificador pode nos assegurar que um programa
está correto - tal garantia não é possível
33. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 33Análise Estática de Código
6. Considerações Finais (1/5)
§ A análise de código-fonte automatizada é uma das técnicas de
inspeções de software
§ automatização de parte do checklist de uma revisão de
código manual
§ A revisão de código encontra todos os defeitos encontrados por
um verificador estático de código
§ disparidade de alertas em alguns tipos de defeitos
§ As ferramentas de análise estática automatizada são eficazes
em encontrar defeitos relacionados aos princípios de
programação estruturada e à manutenibilidade
§ uma excelente prática de programação defensiva
§ Por outro lado, os testes de software detectam defeitos
diferentes
34. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 34Análise Estática de Código
6. Considerações Finais (2/5)
§ Metodologia proposta para a qualidade de um projeto de
software:
1. ferramenta de verificação estática sempre após a compilação
e antes de uma revisão de código manual
2. assim o programa obtém uma indicação inicial de correção
adequada para a realização de testes
35. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 35Análise Estática de Código
6. Considerações Finais (3/5)
§ A ferramenta Checkstyle apresentou-se como a melhor
ferramenta de verificação de regras de estilo
§ A ferramenta Klocwork Developer foi a melhor ferramenta de
verificação de erros alertando sobre todos os erros
§ contudo proprietária, o que faz o FindBugs ser uma
excelente alternativa
36. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 36Análise Estática de Código
6. Considerações Finais (4/5)
§ As ferramentas verificadoras de regras de estilo tendem a
incorporar verificadores para outros propósitos
§ PMD e Checkstyle
§ Isso pode ser bom, por se tornarem mais abrangentes
§ evitar que acabe por não fazer nenhuma das funções
corretamente
§ Por outro lado, as ferramentas verificadoras de erros mantêm
seu foco
37. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 37Análise Estática de Código
6. Considerações Finais (5/5)
§ Nenhuma máquina pode substituir o bom senso, o sólido
conhecimento dos fundamentos, o pensamento claro e a
disciplina
§ Contudo, ferramentas de verificação estática de código podem
efetivamente ajudar os desenvolvedores e, a sua mais ampla
adoção, pode aumentar significativamente a qualidade do
software
38. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 38Análise Estática de Código
Dúvidas?
???