Prof. Emiliano S. Monteiro

Transcrição

1 Prof. Emiliano S. Monteiro

2 Definido como: a probabilidade de falha, operação livre de um programa de computador em um ambiente especificado para um período de tempo especificado (uso controlado do sistema) Pode ser medido diretamente e estimado usando dados históricos e de desenvolvimento (ao contrário de muitos outros fatores de qualidade de software). Problemas de confiabilidade de software geralmente podem ser rastreados até erros de design ou implementação. Usando sistemas de bug trackers (mantis e/ou qdpm)

3 Projeto Tarefas Bugs Ciclo de vida: Aberto analise tratando Fechado Reaberto Encerrado Reaberto Aberto Fechado analise Tratando

4 Contagem de módulos LOC APF Módulos x cronograma em semanas Módulos x pessoas

5 1. Probabilidade de Falha na Demanda = 0,001 Para uma em cada 1000 solicitações, o serviço falha por unidade de tempo. 2. Taxa de Ocorrência de Falha = 0,02 Duas falhas para cada 100 unidades operacionais de tempo de operação.

6 3. Tempo médio de falha (MTTF) Tempo médio até a próxima falha(ou MTBF) 4. Disponibilidade = MTBF / (MTBF + MTTR) MTBF = tempo médio entre falhas MTTR = tempo médio para reparo 5. Confiabilidade = MTBF / (1 + MTBF)

7 Uma métrica de software é uma propriedade de um produto de software, processo ou documentação relacionada que leva um valor numérico que pode ser medido em Linhas de código (LOC) em um programa, número de dias-pessoa necessários para desenvolver um componente, etc. É importante medir (quantificar) a qualidade de um produto de software. Dificuldade principal: distância entre o que queremos saber (geralmente um atributo de qualidade externo) e o que podemos medir (normalmente um atributo interno).

8 Métricas dinâmicas: 1. São coletadas por medições feitas de um programa em execução. 2. Estão intimamente relacionados com atributos de qualidade de software, como eficiência e confiabilidade. 3. É relativamente fácil medir o tempo de resposta de um sistema (atributo de desempenho) ou o número de falhas (atributo de fiabilidade).

9 Métricas estáticas: 1. São coletados por medições feitas das representações do sistema (arquivos de origem, documentação, etc.). 2. Tem uma relação indireta (e difícil de estabelecer) com atributos de qualidade, tais como complexidade, compreensão e manutenção.

10 Número de itens de dados diferentes Número total de campos no banco de dados Número total de campos de entrada nos formulários Número médio de campos por formulário

11 Tempo de execução bruto de um sistema sem interrupção. Hora (no calendário)... se o sistema tiver padrões de uso regulares. Número de transações do sistemas transacional por tipo de operação.

12 Produto de software = programas de computador (fontes e executáveis) + documentação associada. Os produtos de software podem ser: 1. Personalizado - desenvolvido para um cliente específico, de acordo com suas especificações. 2. Genérico ("pacote") - desenvolvido para um mercado geral, para ser vendido a uma gama de clientes diferentes. Off the shelf Software de prateleira.

13 Tipos de produtos de software: 1. Software de suporte empresarial: Software utilizado para manter um determinado negócio operando, 1. ERP Software de gestão sistema integrado 2. Software de desenvolvimento: ferramentas de engenharia de software bem como IDE e compiladores para a produção de artefatos de software, Softwell Maker, Genexus, Scriptcase. 3. Software de produtividade pessoal: Planilhas, ferramentas de processamento de texto,... Software embutido, Office.

14 1. As economias de TODOS os países desenvolvidos dependem do software. 2. Cada vez mais sistemas são controlados por software Incluindo um número crescente de sistemas críticos e de missão crítica, com altas exigências de confiabilidade. 3. Mais e mais empresas dependem do software para o seu sucesso. 4. Software e Sistemas de Informação são fatores críticos de sucesso em um número crescente de empresas e organizações. 5. As despesas de engenharia de software (no desenvolvimento e manutenção de produtos de software) representam uma fração significativa do PIB (Produto Interno Bruto) em todos os países desenvolvidos

15 1. Um programa executando continuamente por um longo período de tempo (sem desligar) pode funcionar cada vez mais lento ou mesmo falhar, por exemplo. 2. Devido a problemas de memória ou fragmentação de memória. 3. A qualidade original é restaurada desligando e reiniciando.

16 Você conhece produtos antigos com problemas de execução? 1. O desempenho diminui com o número de usuários simultâneos e o tamanho dos dados. 2. Pode requerer atualização de hardware e, consequentemente, atualização de software. 3. A manutenção diminui com o tempo. 4. Pode requerer manutenção preventiva (migração para tecnologias conhecidas). 5. O software torna-se obsoleto muito rapidamente: Devido à rápida evolução da tecnologia, requisitos ou conhecimentos. 6. Às vezes o software é usado por mais tempo do que o esperado (bug Y2K) Requer inovação e evolução contínuas.

17 Qualidade do processo: 1. Um bom processo é geralmente necessário para produzir um bom produto! 2. Para os bens manufaturados, o processo é o principal determinante da qualidade. 3. Para a atividade baseada em projeto (como o desenvolvimento de software), outros fatores também estão envolvidos especialmente as capacidades dos projetistas.

18 Para projetos de grande porte com capacidades 'médias', o processo de desenvolvimento determina a qualidade do produto. Qualidade da capacitação e experiência das pessoas: 1. Para projetos pequenos, as capacidades dos desenvolvedores são o principal determinante. 2. Discussão: Você precisa de pessoas com baixa experiência (e processo de qualidade superior) em projetos maiores? 3. Tamanho do Projeto x Pessoas com experiência = Constante?

19 Tamanho do Projeto x Pessoas experientes = Constante? Tecnologia de desenvolvimento: 1. É particularmente importante para pequenos projetos. Orçamento e cronograma: 1. Em todos os projetos, se um cronograma irreal é imposto, a qualidade do produto sofrerá.

20 Encapsulamento (reunião/consolidar) das melhores práticas - evita a repetição de erros passados (SWBOK e o PMBOK). Estrutura para o processo de garantia de qualidade - envolve a verificação da conformidade padrão. Fornecer continuidade - o novo pessoal pode entender a organização por entender os padrões aplicados.

21 Teste de caixa preta: 1. Uma abordagem para testar onde o programa é considerado como uma "caixa-preta. 2. Os casos de teste do programa são baseados na especificação do sistema. 3. O planejamento de testes pode começar cedo no processo de software.

22 Teste de caixa branca: 1. Algum tempo chamado teste estrutural. 2. O conhecimento do programa é usado para identificar casos de teste adicionais. 3. O objetivo é executar todas as instruções do programa 4. As medidas de cobertura de teste garantem que todas as declarações tenham sido executadas pelo menos uma vez.

23 Teste de componentes: 1. Testes de componentes individuais do programa. 2. Geralmente a responsabilidade é do desenvolvedor do componente. 3. Os testes são derivados da experiência do desenvolvedor. Teste de integração: 1. Testes de grupos de componentes integrados para criar um sistema ou subsistema. 2. A responsabilidade de uma equipe de testes independente. 3. Os testes são baseados em uma especificação do sistema (caixa-preta)

24 O nome faz alusão a uma sala limpa para fabricação sob atmosfera controlada. É orientado a equipes. Tem base em controle estatístico. Princípios: Fazer certo da primeira vez evitar ciclos e testes de erros Desenvolvimento incremental, somente a pós cada fase ser aprovada Testes formais de programas Cada teste é uma amostra de uma população e ajuda a estimar a qualidade de um produto.

25 Validação é o processo de afirmar que a especificação de uma etapa ou parte do sistema é apropriada e consistente com os requisitos dos clientes Validação tenta avaliar se a construção do artefato segue o que foi predefinido. Verificação é o processo de determinar se a saída de cada etapa esta de acordo com os requisitos especificados na etapa anterior. Verificar não é demonstrar que a saída etapa do desenvolvimento é correta, mas verificar se o software esta de acordo com as especificações determinadas anteriormente. Verificar consiste em, identificar defeitos e possíveis problemas de um pacote pronto.

26 Foi desenvolvida na década de 90 e permite classificar os defeitos de acordo com diversas dimensões para capturar o máximo de informações.

27 Dimensões: Atividade o momento em que detectado o defeito Gatilho Causa da aparição do defeito Impacto Efeitos sobre o usuário/cliente Alvo Qual a parte que deve ser corrigida Tipo de defeito Correção necessária Qualificador classifica por: omissão, incorreção, excesso Idade se o defeito foi encontrado em um componente novo, reescrito ou já corrigido Fonte: identifica se o componente nasceu com defeito dentro da empresa ou se veio de um módulo de fora da empresa.

28 Propósito Identificador Introdução Itens Funcionalidades Abordagem Critérios de aceite Suspensão Produtos Tarefas de testes Ambiente Responsabilidades Cronograma

29 É uma técnica de observação. Utilizada para compreender os requisitos sociais e organizacionais O analista é inserido no ambiente de trabalho do usuário. O trabalho diário é observado. Ajuda a descobrir requisitos implícitos. Cultura organizacional

30 Ajuda a perceber fatores ambientais, sociais e culturais que afetam o trabalho. Ajuda a evitar que usuário não repassem informações sobre como funcionam seus processos de trabalho.

31 São técnicas de leitura realizadas por um revisor. É uma atividade para validação da documentação gerada durante o processo de software. É uma técnica de leitura de requisitos escritos em linguagem natural. Um dos objetivos é encontrar itens com nomes conflitantes, por exemplo: IdPessoa e MatriculaFuncional, CPF. Cada projeto pode ter mais de um revisor, cada com uma perspectiva de leitura diferente.

32 1. Foco no indivíduo e interações em vez de processos e ferramentas 2. Software executável em vez de documentação 3. Colaboração do cliente ao invés de negociação de contratos 4. Respostas rápidas a mudanças ao invés de seguir planejamento.

33 Descrição formal em linguagem de negócio. Pequenas e simples de capturar Não devem ter mais que um par de páginas. Mais fácil de aplicar em projetos pequenos.

34 Gerentes Operadores Leis e regulamentos Software Compradores Analistas Programadores

35 A palavra JOHARI tem como origem a composição dos nomes dos 2 autores citados acima - nome da ferramenta - JO(seph) e HARI(Harrington). Cada quadrante da janela de Johari é conhecido como: conhecido, cego, oculto e desconhecido. Ela permite, revelar o grau de perceptibilidade nas relações interpessoais entre você e a pessoa que você está realizando o "feedback".

36 Conhecidos por todos Desconhecido para o usuário Requisitos de software Desconhecido para o desenvolvedor Desconhecido por todos

37

38

39 O usuário não solicitou porque achou que a funcionalidade era óbvia O usuário depois de implantado o sistema solicita a inclusão de mais 3 campos em um formulário e mais 2 em um relatório.

40 Nome Versão Descrição Entradas Saídas Sub-rotinas chamadas Efeitos colaterais Casos não tratados Pendências Exemplos de uso Autores

41

42 Um conjunto de tarefas ordenadas constitui um processo, uma séria de etapas que envolvem atividades, restrições e recursos para alcançar a saída desejada. Um processo é um conjunto de procedimentos, organizados de modo que nos permita construir produtos que satisfaçam a uma série de objetivos e padrões.

43 Um processo envolve um conjunto de ferramentas e técnicas, entre elas: a) o processo deve descrever todas as suas atividades b) o processo utiliza recursos e esta sujeito a restrições dos mesmos c) o processo pode ser composto de sub-processos d) cada atividade do processo tem critérios de entrada e saída e) as atividades são organizadas em sequência, com uma ordem de execução f) todo processo tem um conjunto de diretrizes que explicam os objetivos de cada atividade g) restrições e controles podem ser aplicadas a cada atividade.

44 Atualmente existem mais de 100 filosofias de desenvolvimento:

45 Características: Um dos primeiros modelos, proposto por Winston W. Royce, em O desenvolvimento de um estágio deve terminar antes do próximo começar. Só quando todos os requisitos forem enunciados é que a equipe de desenvolvimento pode iniciar suas atividades. Pode ser usado para estimar quando falta para o término do projeto. É fácil de explicar aos clientes. Não reflete como o código é desenvolvido. É frequentemente utilizado na resolução de problemas nunca antes resolvidos. Ao final de cada fase é produzido um artefado, sem detalhar como. Trata o desenvolvimento de software como resolução de problema. Enfoque nos documentos e artefatos.

46 Criado por Barry Boehm em 1988, é similar a um risco envolvido que forma o desenho da espiral. É um modelo incremental e interativo. Requisitos Avaliação e análise de risco Primero concebe as operações, depois gera requisitos, depois desenvolve e finalmente habilita os testes, reiniciando o ciclo novamente. Testes Lançamento Codificação

47 A prototipação pode ser a base de um processo de software. Permite o desenvolvimento rápido para esclarecer dúvidas, reduzindo os riscos e a incerteza do desenvolvimento. O protótipo começa com um conjunto simples de requisitos, quando apresentado aos clientes, este protótipo passa por refinamentos sucessivos, até que um protótipo final tenha sido obtido, permitindo então a codificação final.

48 É uma variação do modelo em cascata. Proposto pelo ministério de defesa da Alemanha em A codificação é o vértice do V, a análise e projeto ficam em um lado e o testes do outro. Durante a verificação de problemas (lado direito), caso encontrados) o lado esquerdo pode ser revisto, permitindo a correção. O modelo V pode ser incrementado com prototipação. Principais desvantagens: Não aborda operações, manutenção, reparo nem descarte de sistemas!

49 Sommervile (2003), na maioria dos projetos de software, ocorre algum reuso de software. Isto acontece quando as pessoas envolvidas no projeto de um software conhece outros projetos similares. Estes softwares similares sofrem pequenas modificações e são incorporados ao novo projeto em desenvolvimento. A abordagem voltada para a componentização de software, também trata do reuso de código entre projetos. Uma categoria de sistemas que se beneficia desta forma de trabalho são softwares de prateleira, pois muitos possuem funções similares, nesta categoria entram pequenas automações comerciais. Sua principal vantagem esta na redução de software a ser produzido, também propicia a redução do tempo de entrega. Sua desvantagem esta no controle sobre a evolução do sistema, pois partes do sistema, componentizadas estão sob controle de terceiros.

50 1. Acceptance Test Driven Development (ATDD) 2. Agile Modeling 3. Agile Unified Process (AUP) 4. Continuous integration (CI) 5. Crystal Clear 6. Crystal Methods 7. Dynamic Systems Development Method (DSDM) 8. Extreme Programming (XP) 9. Feature Driven Development (FDD) 10. Graphical System Design (GSD) 11. Kanban 12. Lean software development 13. Scrum 14. Scrum-ban 15. Story-driven modeling 16. Test-driven development (TDD) 17. Velocity tracking 18. Software Development Rhythms

51 Scrum é um processo iterativo de desenvolvimento incremental de software. Ele vai do desenvolvimento de produto até a entrega da aplicação. Seu foco está em: Ser uma estratégia de desenvolvimento flexível, do produto, onde uma equipe de desenvolvimento funciona como uma unidade para alcançar um objetivo comum. Os criadores (em 1986 foram Hirotaka Takeuchi e Ikujiro Nonaka) descreveram o scrum como: uma nova abordagem para o desenvolvimento de produtos comerciais que aumenta a velocidade e flexibilidade, com base em estudos de caso de empresas de fabricação nas indústrias de fotocopiadoras, automotivo e impressora. Eles chamaram esta abordagem de holística ou rugby, porque todo o processo é realizado por uma equipe multifuncional em várias fases sobrepostas

52

53