Governança e Qualidade em Serviços de TI 1. Fundamentos da Qualidade

1. Governança e Qualidade em Serviços de TI1. Fundamentos da Qualidade Márcio Aurélio Ribeiro Moreira marcio.moreira@pitagoras.com.br http://si.lopesgazzani.com.br/docentes/marcio/

2. História • A humanidade se preocupa com qualidade a muito tempo: • Os egípcios (a mais de 4 mil anos) utilizavam o cúbito (comprimento do braço do faraó) como forma de media nas construções: • Pirâmides com 0,05% de precisão • Grandes templos na Roma antiga e catedrais na França • Grande marco: Revolução Industrial • Início da automação e do consumo em massa  criação de várias indústrias  concorrência  melhoria dos produtos • Década de 1920: • Grande quantidade de produtos • Dificuldade de verificação • Controle estatístico da produção • Diagrama de Walter A. Shewhart

3. História • Década de 1940: • Surgimento de órgãos: • ABNT, ISO, ASQC • Japão se destaca: • Diagrama de Kaoru Ishikawa (espinha de peixe) • Pós-guerra começa a se expandir o uso de computadores

4. Gráfico de Shewhartmodificado por Ishikawa Limite de Especificação Limite de Controle Variação Normal Meta Variação Normal Limite de Controle Limite de Especificação Causa Especial Causas Comuns Regra dos 7 Fora de Controle Causa Especial

5. História • Década de 1950: • Lei de Herbert R. J. Grosch: • Desempenho do computador é proporcional ao quadrado do seu preço • Problemas maiores aquisição de máquinas mais potentes • Mudança da válvulas para transistores  problemas para os softwares: • Aumento significativo da potência das máquinas e inexistência de ferramentas • Década de 1960: • Crise do software  Engenharia de software: • Termo usado pela primeira vez em um congresso na Alemanha em 1968 • Hoje, os problemas são os mesmos mostrados na conferência de 1968 • Cronogramas não observados, projetos abandonados pelas dificuldades • Módulos que não operam corretamente quando combinados • Programas que não fazem o que era esperado ou complexos de utilizar • Programas que simplesmente param de funcionar

6. Crise do software • Somos capazes de produzir software de qualidade? • Existem aspectos não repetitivo do desenvolvimento de software, que torna essa atividade difícil e, sobretudo, em boa medida imprevisível • Gráficos: • Projeto de uma ponte • Projeto de um software • As dificuldades começam nas etapas iniciais: • Na definição do escopo existem requisitos que são voláteis • Ainda existe o Fator Humano: • Devemos conciliar disciplina com o caráter aleatório da criação • Engenharia de Software: • Aplica princípios e métodos da engenharia para ajudar a obter a qualidade de software

7. Linha do tempo Evolução da qualidade Engenharia de Software Anos 60 - Era Funcional Anos 70 - Era do Método Anos 80 - Era do Custo Anos 90 e depois - Era da Qualidade Qualidade não é um fator de vantagem no mercado, mas é uma necessidade para a garantia da competitividade • 1900 - Inspeção pós-produção • 1940 - Controle estatístico • 1950 - Avaliação do processo • 1960 - Educação das pessoas • 1970 - Otimização dos processos • 1980 - Projeto robusto: • Avaliação do processo e do produto • 1990 - Engenharia Simultânea: • Avaliação da própria concepção do produto

8. Definições de qualidade • Philip B. Crosby: • “Conformidade com os requisitos”: • Os requisitos devem ser claramente definidos e não podem ser mal interpretados • A não conformidade = ausência de qualidade • Joseph MosesJuran: • “Conveniência para uso”: • Considera os requisitos e a expectativa do cliente • Um produto deve ter elementos que satisfaçam as diversas maneiras com que os clientes o utilizarão. • Parâmetros da conveniência para uso: • Qualidade de projeto e de conformidade • As duas definições são semelhantes. A de Crosby está mais focada em “como” e a de Juran está focada no uso (resultado)

9. Mais definições • NBR 8402: • A totalidade das características de uma entidade que lhe confere a capacidade de satisfazer as necessidades explícitas e implícitas • Exemplo: • Qualidade de um prato de comida está relacionado com a satisfação das necessidades: sabor, aparência, temperatura, rapidez no serviço, preço, higiene e valor nutricional • Roger S. Pressman: • Conformidade com: • Requisitos funcionais e de desempenho definidos • Padrões e convenções de desenvolvimento pré-estabelecidos • Características implícitas que todo software desenvolvido profissionalmente deve possuir

10. Qualidade e requisitos • Como julgar a qualidade? • Estabelecimento de critérios • Ligação dos requisitos com a qualidade esperada: • Qualidade = f(requisitos) • Avaliação da definição de Crosby: • A qualidade é a conformidade com os requisitos • Três fatos perturbam essa definição: • O que é conformidade? Nós devemos definir o que significa este termo • Nível de qualidade = • Ainda temos que definir uma unidade de medida para obter a qualidade • Observação do produto: Toda observação tem uma margem de erro inerente • Nível de qualidade = • Diferentes clientes em um mesmo projeto: • Diferentes necessidades  diferentes requisitos que podem ter conflitos

11. O papel da subjetividade • O propósito da qualidade é satisfazer o cliente • Nenhum cliente compra um produto pensando exclusivamente em suas propriedades mecânicas • A especificação dos requisitos em vários aspectos é incompleta • Além das propriedades, o custo é fator integrante da qualidade • Logo, para satisfazer uma pessoa é preciso saber claramente do que ela precisa

12. Qualidade e bugs • Qualidade e bugs são conceitos incompatíveis? • Programa pode ter erros e continuar sendo um produto de qualidade: • O dilema gerencial: • Erro num programa de edição de textos que afeta apenas 1% dos usuários, se corrigido poderia gerar mais bugs • A importância relativa I: • Objetos atravessando paredes em jogos é um problema? • A importância relativa II: • Processador TeX é de qualidade comprovada, no entanto não indicado para todas as utilizações • 1º Bug da Computação: • 1947 no Mark II: • Uma abelha provocou falhas no Mark II durante testes

13. Qualidade e bugs • Qualidade não pode ser tratada como dogma: • Não cometa erros!! • Fatores que devem ser considerados: • Tamanho e complexidade do software • Número de pessoas envolvidas • Ferramentas utilizadas • Custos associados a existência de erros • Custos associados a detecção e remoção de erros • Exemplos de relatividade a considerar: • Estudante: Enrolado no final do semestre, aceita um 7 por alguns erros • Programador: Sempre diz “vou atrasar a entrega e fazer mais testes”? • Militar: Vai deixar de incluir revisões e testes no projeto de um míssil? • Devemos sim perseguir o máximo de qualidade que os custos permitem

14. Mito e verdades • Mito: • Criar programas é uma arte que não pode seguir regras, normas ou padrões • Verdades: • Produtos de software são complexos • Software não tem produção em série, a maior parte do custo está no projeto e desenvolvimento • Software não se desgasta (ele pode diminuir o desempenho e a aderência) • Software é intangível. Logo, sua representação em grafos e diagramas não é 100% precisa • A Engenharia de Software ainda não está madura, é uma ciência em evolução • Não há um único ponte de vista entre os profissionais sobre o que é qualidade de software

15. Conceitos base • Defeito: • Imperfeição do produto • Segundo o dicionário: é um programa que não funciona como deve • Exemplos: • A = B / C; Se C = 0 então teremos uma divisão por zero • A = B * C; Se B & C estão no limite, A pode não caber o resultado • Estes defeitos podem não causar falhas, mas são graves • Falha ou Bug: • Resultado errado provocado por um defeito ou condição inesperada • Defeitos podem existir sem, no entanto, provocarem falhas • Falhas podem ocorrer por fatores externos: • Toda falha potencial é perigosa, mesmo as que não travem o programa • Lei de (EdsgerWybe) Dijkstra: • Os testes podem ser uma forma muito eficaz de mostrar a presença de falhas. Mas, são fortemente inadequados para mostrar a ausência de falhas

16. Entraves à qualidade (IEEE610.12-1990)

17. Causas de falhas • Alterações: • As mudanças alteram a estrutura do software tornando-o cada vez mais difícil de alterar e podem introduzir novas falhas • Tempo: • Com o tempo o custo de implementação de alterações aumenta e a capacidade do sistema de prestar os serviços esperados diminui • Complexidade: • O desenvolvimento é complexo e, normalmente, um único desenvolvedor não é capaz de entender o sistema como um todo • Os softwares estão cada vez mais difíceis de utilizar (janelas, eventos, leis, necessidades conflitantes, etc.) • Os softwares estão cada vez mais difíceis de entender devido a códigos mal documentados ou incompreensíveis

18. O que fazer diante de um defeito, falha ou bug? • Isolar um defeito: • Determinar sob quais condições a falha ocorre • Descobrir qual linha de código provoca a falha: • Pode ser bastante difícil (depuração do código) • Identificar a causa do defeito • Corrigir o defeito: • Corrigir o defeito e testar fora de produção • Aplicar a mudança no ambiente de produção • Estabilizar um programa: • Fazer correções para diminuição da frequência de falhas • Mais tempo de uso significa mais possibilidade de encontrar e corrigir problemas

19. Catástrofes da qualidade • Defeitos não constituem o único fator de qualidade • O usuário pode conviver com a falha e o programa ser um sucesso ou causar um completo fracasso comercial • Ariane 501: • Foguete lançado em 1996 explodiu 40s depois de decolar • Falha de software foi interpretada como comando • Therac-25: • Terapia radiológica controlada por computador (software) • Erros no software provocaram a morte de 6 pacientes

20. Qualidade e SWEBOK • Quantidade de informação aumentou de tal forma que especialização tornou-se comum (senão necessária) • Estudo técnico para delimitação das fronteiras da engenharia de software • SWEBOK (Software Engineering Body of Knowledge ou Corpo de Conhecimento de Engenharia de Software) • 11 Áreas de Conhecimento ou Disciplinas: • Requisitos, projeto, construção, testes, manutenção, gestão de configuração, gestão de engenharia, processos de gestão, métodos e técnicas de engenharia e qualidade • Qualidade: técnicas estáticas (qualidade) e dinâmicas (testes) • Na verdade, qualidade tem algo em comum com toas as subáreas • Divisão hierárquica

21. Hierarquia da qualidade no SWEBOK • Fundamentos de qualidade: • Definição de qualidade  Definição de requisitos  Modelo • Prejuízos causados pela falta de qualidade e custos • Processos de gerência de qualidade: • Todos os aspectos da construção de um produto • Assegurar que os objetivos planejados serão cumpridos • Considerações práticas: • Recomendações gerais sobre como transcorre a execução de atividades relacionadas com qualidade

22. Certificações de qualidade • Além da qualidade existir, ela deve ser reconhecida pelo cliente • As certificações de qualidade são emitidas com base em padrões e num processo de certificação • INMETRO: Responsável pelas instituições de certificação • Exemplos: • O selo do SIF (Serviço de Inspeção Federal) • O selo da ABIC (Associação Brasileira da Indústria de Café) • A classificação em estrelas dos hotéis () • Certificados ISO (International Organization for Standardization) • Certificados IEEE (Institute of Electrical and Electronics Engineers) • Certificados INMETRO (Instituto Nacional de Metrologia)

23. Dimensões daqualidade • Qualidade do produto: • Características que o produto deve ter para possuir qualidade: • Funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade (ISO 9126 e NBR 13596) • Qualidade do processo: • Para entregar um produto com qualidade, o que precisamos fazer durante o processo de desenvolvimento do software: • Todas as etapas da engenharia de software (requisitos, projeto, etc.) podem comprometer a qualidade do produto • Software Quality Assurance: • Padrão sistemático e planejado de ações que são exigidas para garantir a qualidade de software. Essas ações englobam: • Aplicações de métodos técnicos Realizações de revisões técnicas formais • Atividade de teste de software Aplicação de padrões e procedimentos formais • Processo de controle de mudanças Mecanismos de medição

24. Técnicas aplicadas durante o projeto

25. Principais normas de qualidade

26. Modelo de qualidade de McCall de 1977 • Adaptação a novos ambientes: • Portabilidade • Reusabilidade • Interoperabilidade • Características operacionais: • Corretude • Confiabilidade • Consistência • Eficiência • Integridade • Usabilidade • Habilidade de ser alterado: • Manutenibilidade • Flexibilidade • Testabilidade

27. Características operacionais • Corretude: • Quanto o programa satisfaz sua especificação e cumpre os objetivos do cliente • Confiabilidade: • Quanto um programa executa a função pretendida com a precisão exigida • Consistência: • O uso do software não provoca inconsistência nas informações • Eficiência: • Quantidade de recursos computacionais e de código exigida para que um programa execute sua função • Integridade: • Quanto o acesso ao software ou aos dados por pessoas não autorizadas pode ser controlado • Usabilidade: • Quanto de esforço é necessário para aprender, preparar a entrada e interpretar a saída de um programa

28. Habilidade de ser alterado • Manutenibilidade: • Quanto de esforço é necessário para localizar e eliminar erros em um programa • Flexibilidade: • Quanto de esforço é necessário para modificar um programa • Testabilidade: • Quanto de esforço é necessário para testar um programa a fim de garantir que ele execute a função pretendida

29. Adaptação a novos ambientes • Portabilidade: • Quanto de esforço é necessário para transferir um programa de uma plataforma de hardware e/ou software para outra • Reusabilidade: • Quanto um programa (ou partes dele) pode ser reutilizado em outros programas • Interoperabilidade: • Quanto de esforço é necessário para se acoplar um programa a um outro

30. ISO 9126 ou NBR 13596

31. ISO 9126 ou NBR 13596

32. Qualidade x Tipo de Software • Cada tipo de software tem seu próprio requisito de qualidade • A importância de cada característica depende do tipo de software • Exemplos: Sistema para videolocadora Sistema embarcado para satélite

33. Qualidade x Pontos de Vista

34. Como aplicar a norma ISO 9126 ou NBR 13596? • Qualidade do produto: • Atribuir notas ou conceitos para cada uma das subcaracterísticas • Sem estar familiarizado com o processo de avaliação de software não é fácil aplicar a norma • Existem guias para avaliação de qualidade do software: • Eles descrevem os passos para se avaliar um software • Qualidade do processo (certificação): • Para melhorar a qualidade no desenvolvimento precisa-se de modelos de processos para a descrição precisa e formal das atividades do ciclo de vida do software • Modelo de Processo é representado por um conjunto sequencial de atividades, objetivos, transformações e eventos que encapsulam estratégias para o cumprimento da evolução do software

35. Gestão do processo de software Princípios Modelo de avaliação • A gerência de processo visa a geração de produtos de acordo com o planejado e, ao mesmo tempo, melhorar a capacidade de produzir software com mais qualidade • Para a evolução do processo de software é necessário ter uma maneira para medi-lo

36. Métodos de avaliação de processos • Métodos de avaliação: • CMM: Capability Maturity Model • PSP: Personal Software Process • ISO 9000-3 • Projeto SPICE (ISO/IEC 15504) • Projeto SQUID, etc.

37. Níveis de maturidade em processo Centrados em Negócios Centrados em Tecnologia

38. ISO 9000-3 • ISO 9000-3: • Guia para a aplicação da ISO 9001 para o desenvolvimento, fornecimento e manutenção de software, criado em 1993 • Especifica requisitos mínimos para assegurar a qualidade de produtos e serviços, não definindo modelos ou impondo sistemas de qualidade • Atividades do ciclo de vida: • Análise crítica do contrato • Especificação dos requisitos do comprador • Planejamento do desenvolvimento • Planejamento da qualidade • Projeto e implementação • Ensaios e validação • Aceitação • Cópia, entrega e instalação • Manutenção

39. ISO 9000-3 • Atividades de Suporte: • Gestão de configuração • Controle de documentos • Registros da qualidade • Medição • Regras, práticas e convenções • Ferramentas e técnicas • Aquisição • Produto de software incluído • Treinamento

40. SPICE • Software Process Improvement and Capability dEtermination • Motivação: • Mortalidade dos trabalhos de padronização • Organização: • 4 Centros Técnicos • Conselho Administrativo • Organizações privadas e estatais • O que é? • É um conjunto de documentos • Consiste de um framework de avaliação: • Facilita o autojulgamento Desperta consciência do contexto • Produz um perfil do processo Direciona a adequação das atividades • Apropriado para organizações de diversos tamanhos

41. SPICE Aplicação • Aplicado para organizações envolvidas com qualquer atividade relacionada ás atividades de computação • A Avaliação examina o processo e determina a efetividade deste • Resultados podem usados para: • Auto avaliação • Melhoria do processo • Componentes: • 1: Conceitos e Guia Introdutório • 2: Modelo de Gestão de Processo • 3: Avaliação do Processo • 4: Guia para Condução de uma Avaliação • 5: Construção, Seleção e Uso das Ferramentas de Avaliação • 6: Qualificação e Treinamento dos Avaliadores • 7: Guia para o Processo de Melhoria • 8: Guia para Orientação da Determinação da Capacidade do Processo • 9: Dicionários

42. Quadro comparativo

43. Quadro comparativo

44. Quadro comparativo

45. Conclusões • Dos métodos de avaliação de processo apresentados, alguns estão estabelecidos no mercado (CMM), e outros apresentam projetos ambiciosos a nível mundial (SPICE) • Dentre estes, existem modelos que além de avaliar o processo de desenvolvimento propõem algum mecanismo para melhoria do processo • Não existe um modelo ideal de avaliação de qualidade que seja aplicável indistintamente às organizações, abrangendo os diversos objetivos que elas tem em relação a qualidade • A qualidade de software é garantida pela qualidade de processo e pela garantia de qualidade do produto final • O foco da qualidade deve ser sempre a satisfação do usuário final

46. Referências

47. Obrigado!