Prof. Emiliano S. Monteiro

Transcrição

1 Prof. Emiliano S. Monteiro

2 O estudo da qualidade permite possamos monitorar os produtos de software, detectar problemas mais cedo e criar a cultura do aprimoramento constante. A qualidade de software começa desde o projeto do sistema, muito antes de qualquer linha de código ter sido escrito e acompanha o software até a sua desativação.

3 A qualidade é a conformidade aos requisitos

4 1)A qualidade de um produto é dada pela diferença entre as características observadas e as características que foram especificadas para sua construção 2)Erros de medição que podemos controlar 3)Pontos de vista de diferentes stakeholders(clientes [partes interessadas])

5 Como definir esta subjetividade? Veja o exemplo: Quais critérios são usados para a compra de um carro? Quais critérios são usados para a construção de um carro? Incluir o custo na equação.

6 1)Quando implica em aumento de custo sem retorno ao investimento 2)Defeitos aceitáveis, como nos jogos 3)A complexidade de determinado software nos obriga a usar outro menos complexo diminuindo custo e treinamento, veja o exemplo do uso de interfaces caracteres contra interfaces gráficas

7 Complexidade do projeto e produto final Quantidade de recursos humanos envolvidos no projeto Ferramentas utilizadas Técnicas utilizadas Custos e prazos para a construção Custos e prazo para detecção e correção de erros Quebrando em partes menores Menos é melhor Adianti Framework Wordpress Scrum Beta tester

8 Medir a qualidade do software é motivada por pelo menos duas razões: 1. Gerenciamento de Risco: As falhas de software causaram mais do que travamentos. Erros de software causaram mortes humanas. As causas variaram de interfaces de usuário mal projetadas até erros de programação direta. 2. Gerenciamento de Custos: Como em qualquer outro campo de engenharia, uma aplicação com boa qualidade de software estrutural custa menos para ser mantida e é mais fácil de entender e mudar em resposta às necessidades urgentes das empresas. A fraca qualidade estrutural está fortemente correlacionada com interrupções de negócios de alto impacto devido a dados corrompidos, interrupções de aplicativos, falhas de segurança e problemas de desempenho.

9 A perspectiva transcendental lida com o aspecto metafísico da qualidade. Nesta visão de qualidade, é "algo em relação ao qual nos esforçamos como ideal, mas nunca podemos implementar completamente". A perspectiva do usuário está relacionada com a adequação do produto para um dado contexto de uso. Visão mais concreta, fundamentada nas características do produto. A perspectiva de fabricação representa a qualidade como conformidade com os requisitos.

10 A perspectiva do produto implica que a qualidade pode ser apreciada medindo as características inerentes do produto. A perspectiva do valor: Esta perspectiva reconhece que as diferentes perspectivas de qualidade podem ter diferentes importância, ou valor, para várias partes interessadas (stakeholder). Valor = importância no contexto de uso

11 Práticas de Arquitetura de Aplicativos Práticas de Codificação Complexidade de Aplicação Documentação Portabilidade Volume técnico e funcional 1. Confiabilidade 2. Segurança 3. Eficiência 4. Manutenção 5. Tamanho

12 Um erro de software é uma falha, falha em um programa de computador ou sistema que faz com que ele produza um resultado incorreto ou inesperado, ou se comportar de maneiras não intencionais. O termo "bug" para descrever defeitos tem sido uma parte do jargão de engenharia de software por muitas décadas e é anterior aos computadores e software de computador; Ele pode ter sido originalmente usado na engenharia de hardware para descrever avarias mecânicas.

13 1. Um prazo deve ser cumprido e os recursos são insuficientes para corrigir todos os bugs. 2. O bug será corrigido em uma próxima versão, e não é de alta prioridade. 3. As alterações necessárias para corrigir o bug são muito caras ou afetam muitos outros componentes, exigindo uma grande atividade de teste. 4. O problema está em uma área que será obsoleta com uma liberação futura; Corrigir é desnecessário. 5. Não é "um bug". Um mal-entendido surgiu entre o comportamento esperado e percebido. Falso positivo.

14 O Guide to the Software Engineering Body of Knowledge (SWEBOK) descreve conhecimentos geralmente aceitos sobre engenharia de software. Suas 15 áreas de conhecimento (KAs) resumem conceitos básicos e incluem uma lista de referência apontando para informações mais detalhadas. Ele pode ser baixado em: É um padrão internacional : ISO 19759:2005

15 Requisitos de software Design de software Construção de software Teste de software Manutenção de software Gerenciamento de configuração de software Gerenciamento de engenharia de software Processo de engenharia de software Modelos e métodos de engenharia de software Qualidade do software Prática profissional em engenharia de software Economia de engenharia de software Fundações computacionais Fundamentos matemáticos Fundações de engenharia

16 Engenharia Informática Engenharia de sistemas Gerenciamento de Projetos Gestão da Qualidade Administração Geral Ciência da Computação Matemática

17 Qualidade de software Fundamentos da qualidade de software Processos de gerência de qualidade de software Considerações práticas Valor e custo Garantia da qualidade Verificações e validações Auditoria Requisitos Caracterização de defeitos Gerenciamento

18 Visa assegurar que o nível de qualidade requerido é atingido pelo software. Envolve a definição apropriada de procedimentos e padrões de qualidade. Deve proporcionar uma cultura da qualidade onde esta seja vista como uma responsabilidade de cada um dos envolvidos. Não é apenas reduzir defeitos, mas garantir outras qualidades do produto.

19 1. Com métodos e ferramentas de análise, projeto, codificação e teste; 2. Com revisões técnicas formais que são aplicadas durante cada fase da engenharia de software; 3. Usando uma estratégia de teste de múltiplas fases; 4. No controle da documentação do software e das mudanças feitas nela; 5. Com um procedimento para garantir a adequação aos padrões de desenvolvimento de software, se eles forem aplicados; 6. Com mecanismos de medição e divulgação de resultados. Scrum StarUML MS Project Testes de integração Doxygen Processo de software IDE, Graylog, eureka log, Mantis Bug Tracker

20 O SRS (Software Requirements Specification [Especificação de requisitos de software]) é basicamente a compreensão de uma organização e cliente (por escrito) de um requisitos do sistema para este potencial cliente e realizado em determinado ponto no tempo (geralmente) antes de qualquer projeto real ou trabalho de desenvolvimento tenha início. É uma apólice de seguro de duas vias, que assegura que tanto ao cliente como para a organização entender as necessidades de ambas as partes. SRS é a base de processos de fiscalização.

21

22 Defeito é uma imperfeição física (ou lógica) de um produto. O defeito é parte integrante de um produto acabado. Programas defeituosos são programas que não se comportam como o esperado.

23 É o produto não desejado gerado pelo defeito ou uma condição não desejada. A falha pode ser causada pelo defeito ou por eventos externos como: corrupção de uma base de dados, problemas com a memória, etc. Defeito (origem) Falha (resultado)

24 Interferências na medição

25 Evitar informalidades Fontes: medições automatizadas ou com interferência humanas. Exemplos de ruídos: cache, trafego de rede, fadiga do hardware, fadiga do operador, rpm do hd, interferência de outros programas no compartilhamento de tempo da cpu, etc

26 Habilidade motora e cognitiva Nível de atenção Motivação para realização a tarefa Desconforto (de vários tipos) Fatores ambientais

27 Isolar um defeito significa identificar as condições nas quais o defeito ocorre, principalmente identificando linha(s) de código que originam o defeito. O uso de Add watch, breakpoint e Tracers auxiliam nesse processo. Estabilizar um software é aplicar correções para que os defeitos sejam neutralizados, diminuídos ou corrigidos. As aplicações de service packs são um exemplo disso.

28 1.Dois clientes compra um mesmo carro, terão eles opiniões diferentes sobre o veículo, isso é um exemplo de ruído de medição?

29 2. Um programa que não tem defeitos pode falhar?

30 3. Qual a diferença entre isolar defeitos e isolar falhas?

31 4. Uma planilha foi utilizada por um usuário para abrir um arquivo MP3, e com isso o software foi abortado, onde está o defeito? a)na interface gráfica do usuário b)no treinamento do usuário c)nas mensagens ao usuários d)na programação do software e)na documentação do software

32 5. Uma planilha foi utilizada por um usuário para abrir um arquivo MP3, como evitar que o software seja travado ou aborte a execução?

33 De facto: são padrões de qualidade adotados amplamente por uma determinada comunidade, mesmo não tendo sido formalizado como uma norma internacional por uma entidade publicamente reconhecida, é o que foi caso da linguagem PERL. De Jure: São padrões criados formalmente por instituições como a ISO, IEEE, ABNT, etc...

34 Fundada em 1940 (também é um membro da ISO) Possui comitês responsáveis por vários estudos, o comitê responsável pela computação é o CB-21 (computadores e processamento de dados). Alguns sub comitês da CB-21: Qualidade de software Gerência do ciclo de vida Estimativa de tamanho de software (ponto por função) Ergonomia

35 Qualquer empresa pode a qualquer momento adotar um padrão sem passar por nenhuma certificação de terceiros. A certificação é realizada por uma entidade idônea e independente, e não deve possuir nenhum vínculo com a empresa que está sendo certificada.