ESELAW Mini-Curso: Revisão e Inspeção de Software

Transcrição

1 ESELAW 2007 Mini-Curso: Revisão e Inspeção de Software Guilherme Horta Travassos Estrutura do Mini-Curso Conceitos Básicos sobre Revisão e Inspeção de Software O processo de Inspeção de Software Inspeção Ad-hoc Inspeção com Checklist ArqCheck: inspeção de modelos arquiteturais Técnicas de Leitura OO-PBR: inspeção de requisitos OORTs: inspeção de projeto Apoio Automatizado para Inspeção Dicas para conduzir uma boa inspeção Sugestão de Bibliografia

2 Definições Engenharia de Software: Conjunto de princípios, métodos e técnicas que tratam o software como produto de engenharia que requer planejamento, projeto, implementação e manutenção. Objetivo Principal: Produzir software com alta qualidade e baixo custo. Definições Qualidade de Software Conformidade com requisitos funcionais e de desempenho, padrões de desenvolvimento documentados, e características implícitas esperadas de todo software profissionalmente desenvolvido. Corretude Confiabilidade Testabilidade Garantia de Qualidade de Software Conjunto de atividades técnicas aplicadas durante todo o processo de desenvolvimento. O objetivo é garantir que tanto o processo de desenvolvimento quanto o produto de software atinjam níveis de qualidade especificados.

3 Definições Garantia de Qualidade de Software Verificação: Assegurar consistência, completude e corretude do produto em cada fase e entre fases consecutivas do ciclo de vida do software. Estamos construindo corretamente o produto?. Validação: Assegurar que o produto final corresponde aos requisitos do software. Estamos construindo o produto correto?. Teste: Examina o comportamento do produto através de sua execução. Definições Defeito Erro Falha Defeito: deficiência mecânica ou algorítmica que se ativada pode levar a uma falha. Erro: item de informação ou estado de execução inconsistente. Falha: evento notável onde o sistema viola suas especificações.

4 Defeitos no Desenvolvimento de Software Defeitos no Desenvolvimento de Software A maior parte é de origem humana. São gerados na comunicação e na transformação de informações. Permanecem presentes nos diversos produtos de software produzidos e liberados. A maioria encontra-se em partes do produto de software raramente utilizadas e/ou executadas.

5 Defeitos no Desenvolvimento de Software 1. Informação transformada corretamente. 2. Informação perdida durante a transformação. 3. Informação transformada incorretamente. 4. Informação estranha introduzida. 5. Ocorrência de múltiplas transformações inconsistentes a partir de uma mesma fonte de informação. 6. Possibilidade de múltiplas transformações inconsistentes a partir de uma mesma fonte de informação. Defeitos no Desenvolvimento de Software Principal causa: tradução incorreta de informações. Quanto antes a presença do defeito for revelada, menor o custo de correção do defeito e maior a probabilidade de corrigi-lo corretamente. Solução: introduzir atividades de VV&T ao longo de todo o ciclo de desenvolvimento.

6 Defeitos Introduzidos ao longo do Processo de Desenvolvimento De onde os defeitos vem? Que defeitos nós podemos encontrar? Conhecimento do Domínio Requisitos Gerais Fato incorreto Outro Domínio Informação estranha omissão Artefatos de Software Defeito Omissão Fato Incorreto Inconsistência inconsistência Descrição Geral Informação necessária sobre o sistema foi omitida do artefato de software Alguma informação no artefato de software contradiz informação do documento de requisitos ou o conhecimento geral do domínio. Informação contida em uma parte do artefato de software está inconsistente com outra informação no artefato de software Ambiguidade Informação contida no artefato de software é ambigua, isto é, várias interpretações podem ser derivadas da definição levando o desenvolvedor a implementação incorreta Informação Estranha Informação que é fornecida não é necessária ou nunca utilizada ambigüidade Garantindo a Qualidade do Software Mito: Não é possível testar até que o sistema exista... FATOS: Testar é muito mais do que apenas ver o que vai acontecer E muito mais que apenas executar casos de teste! Documentos de requisitos podem e devem ser testados em relação aos objetivos do negócio ou projeto para assegurar completude e correção.

7 Documento de Especificação de Requisitos de Software primeiro artefato tangível a ser produzido descreve todas as características e as funções que o software a ser desenvolvido deve possuir atua como um contrato entre o cliente e o desenvolvedor base para todas as etapas subseqüentes do desenvolvimento normalmente escrito em linguagem natural. Garantindo a Qualidade do Software Mito: Desenvolvedores devem pensar nos requisitos apenas no início do desenvolvimento, e se preocupar com testes apenas no final... FATOS: ter os testadores envolvidos durante a análise de requisitos é uma das melhores formas de se assegurar requisitos de boa qualidade Trocas tardias nos requisitos causam impacto nos testes Ter os usuários envolvidos nos requisitos e nos testes é fundamental!

8 Garantindo a Qualidade do Software Mito: Requisitos são utilizados no teste, mas não o contrário... FATOS: Você não testa requisitos, mas testa a partir deles! É fácil escrever requisitos vagos ou ambíguos, que parecem estar ok. Quando bons testadores observam a especificação de requisitos, eles aconselham casos de teste específicos para acertar os requisitos vagos, ambíguos ou não muito explícitos. Boa engenharia de requisitos produz melhores testes; boa análise de testes melhora os requisitos! Garantindo a Qualidade do Software Mito: Se escrever testes é difícil, isto é somente um problema dos testadores... FATOS: Nem todos os requisitos são criados de acordo com a mesma perspectiva do testador. Para alguns dos requisitos fica fácil definir o teste, para outros um verdadeiro pesadelo! Especificar requisitos não funcionais testáveis tais como usabilidade ou desempenho é difícil Frases como fácil de usar, interface amigável, muito confiável ou desempenho aceitável não são especificações!

9 Ambigüidade em Linguagem Natural Navegar é preciso Viver não é preciso Pompeu, 56 A.C. citado por Fernando Pessoa Tipos de Defeitos Encontrados em Requisitos Tipo Percentagem(%) Fato Incorreto 40 Omissão 31 Inconsistência 13 Ambigüidade 5 Localização Incorreta 2 Adaptado de (DAVIS,1990).

10 Conseqüências estimativas de esforço e prazo deixam de fazer sentido desperdício de recursos produto final não atende as necessidades do usuário corrigir defeitos após a entrega do produto pode ser até cem vezes mais caro que corrigi-los nas primeiras fases do desenvolvimento (em projetos menores, 5:1) em projetos recentes de software, teríamos um esforço de retrabalho entre 40% e 50% do esforço total Garantindo a Qualidade do Software Mito: Os testadores não precisam dos requisitos FATOS: O sistema deve apoiar o negócio a atingir um objetivo, então o que o sistema realmente faz deve ser comparado com este objetivo. Uma especificação de requisitos representa o oráculo para o teste! Sim, testadores precisam dos requisitos, caso contrário, você poderia argumentar que o que vem sendo executado não é realmente um teste!

11 Eficiência das Técnicas para a Identificação e Correção de Defeitos ATIVIDADE EFICIÊNCIA Revisões informais de projeto 25% a 40% Inspeções formais de projeto 45% a 65% Revisões informais de código 20% a 35% Inspeções formais de código 45% a 70% Teste de unidades 15% a 50% Teste de integração 25% a 40% Teste do sistema 25% a 55% Beta-teste (< 10 clientes) 24% a 40% Beta teste (> 1000 clientes) 60% a 85% Capers Jones, Software defect-removal efficiency, IEEE Computer, março 1996 Inspeção de Software termo introduzido por Michael Fagan, na década de 70, em seu artigo Design and Code Inspections to Reduce Errors in Program Development ; tem sido o tipo de revisão de software mais estudado e utilizado (CHRISTIENSEN et al.,2001); Objetivos: Identificar defeitos específicos num documento ou sistema; Identificar erros sistemáticos no processo de desenvolvimento; Identificar desvios em relação à especificações e padrões. Benefícios: provê ganhos significativos em relação a prazos e custos; tende a encontrar mais defeitos que qualquer outro processo, e a um custo menor (GLASS,1999).

12 Inspeção de Software Revisões e Inspeções no início apenas código atualmente, inspeções são amplamente utilizadas e estudos têm mostrado que são um método eficaz para o controle de qualidade e tendem a melhorar a produtividade. It s a formal, peer evaluation of a software element whose objective is to verify that the software element satisfies its specifications and conforms to standards IEEE Standard for Software Reviews and Audits O processo de inspeção depende da técnica que está sendo utilizada O objetivo primário das inspeções é identificar defeitos em diferentes estágios do projeto. Revisões são técnicas semi-formais. Um exemplo é o Walkthrough Walkthroughs Alternativa com um processo menos rigoroso do que o de inspeções de software. Papéis sugeridos: Líder, Autor, Escrivão e Revisores Procedimento: Os participantes são guiados através dos artefatos pelo líder (que eventualmente é o próprio autor) em uma reunião. Durante esta reunião devem interromper a apresentação caso encontrem defeitos. Muitas vezes condições de entrada e saída e decisões são pressupostos pelo líder que segue sua linha de raciocínio durante a apresentação.

13 Walkthroughs Possuem custo aproximadamente igual ao de inspeções mas seus resultados são inferiores (SEI, 2005): Não providenciam resultados mensuráveis; Não fornecem base para a aplicação de controle estatístico de processos, necessário para evoluir na maturidade de processos de software. Podem ser utilizados para atividades de brainstorming, para explorar alternativas de projeto e resolução de problemas. Inspeções são mais focadas em encontrar defeitos. Inspeção de Software Benefícios e Custo de Inspeções inspeções vêm sendo utilizadas há mais de três décadas existe evidência experimental de sua usabilidade e adequabilidade provêem um bom meio para gerenciar a qualidade e progresso do projeto; podem amenizar atividades de manutenção, evitando que defeitos se propaguem pelo ciclo de vida; apresentam baixo custo devido ao fato do revisor não precisar investir muito tempo ou mesmo não demandar ferramentas sofisticadas para realizá-las. Observa-se que uma alta taxa de atividades de inspeção ao longo do processo pode acrescer de 5% a 10% o custo final

14 Afinal, o que é inspeção de software? Definição: Método de análise estática para verificar propriedades de qualidade de produtos de software. Dimensões: Estruturada, processo bem definido Pessoal técnico Papéis bem definidos Técnicas de leitura para identificação de defeitos Resultados documentados Benefícios de Inspeções Identificação mais cedo de defeitos

15 Benefícios de Inspeções Inspeções em requisitos e projeto, conduzidas no JPL (Miller,1990); Fase Requisitos Fase Projeto Fase Teste Unid. Fase Teste Sist. Total Defeitos Req. Defeitos Proj. Outros Total Benefícios de Inspeções Teoria: Inspeções melhoram a produtividade encontrando defeitos nos momentos em que sua correção é mais barata. Inspeções podem melhor a produtividade e reduzir o custo

16 Benefícios de Inspeções: Identificação mais cedo de defeitos Inspeções podem melhor a produtividade por permitir encontrar defeitos quando estes são mais fáceis de identificar e corrigir: Horas para encontrar um defeito (JSC): Cedo no projeto Tarde no projeto 1.2 (fácil), 1.4 (difícil) 1.5 (fácil), 3 (difícil) Horas para corrigir um defeito (JPL): Inspeções 0.7 Testes 5 a 18 Benefícios de Inspeções Quantitativos: Primary Avionics Software System, JPL Inspeções em requisitos, projeto, código, plano de testes, especificações e procedimentos. Taxa de Defeitos reduzidas de 2.25 para 0.08 defeitos/ksloc Qualitativos: Aprendizado por experiência: Participantes aprendem padrões de defeitos; Participantes aprendem bons padrões de desenvolvimento. No longo prazo... Inspeções convencem os participantes a desenvolver software mais fácil de entender e manter.

17 Inspeções de Software Artefato Software Como conduzir uma inspeção? Organizador 1 Planejamento Form. Planejamento Ad-hoc, Checklist, Técnicas de leitura Inspetor Deteção 2 Form. Relato Defeito Papéis moderador inspetor autor Coleção 3 Form. Relato Defeito Atividades Produtos autor Correção 4 Form. Relato Defeito Artefato Software Corrigido Inspeções de Software Processo Tradicional de Inspeção de Software (Fagan, 1976)

18 Processo Tradicional de Inspeção de Software Planejamento. Um usuário, desempenhando o papel de moderador da inspeção, define o contexto da inspeção (descrição da inspeção, técnica a ser utilizada na detecção de defeitos, documento a ser inspecionado, autor do documento, entre outros), seleciona os inspetores e distribui o material a ser inspecionado. Apresentação. Os autores dos artefatos a serem inspecionados apresentam as características destes. Esta fase pode ser omitida se os inspetores possuem conhecimento sobre o projeto e os artefatos que devem ser inspecionados. Preparação Individual. Os inspetores estudam os artefatos individualmente, e eventualmente fazem anotações sobre estes produzindo uma lista de discrepâncias. O fornecimento de técnicas de leitura pode facilitar a execução desta tarefa. Processo Tradicional de Inspeção de Software Reunião de Inspeção. Uma reunião em equipe ocorre, envolvendo o moderador, os inspetores e os autores do documento. Discrepâncias são discutidas, e classificadas como defeito ou falso positivos. A decisão final sobre a classificação de uma discrepância sendo discutida é do moderador. A solução dos defeitos não é discutida durante a reunião, que não deve exceder duas horas, uma vez que após este tempo a concentração e a capacidade de análise dos inspetores costuma reduzir drasticamente. No caso em que uma reunião precisar de mais de duas horas, é sugerido que o trabalho de inspeção continue no próximo dia. Retrabalho. O autor corrige os defeitos encontrados pelos inspetores e confirmados pelo moderador. Continuação. O material corrigido pelos autores é repassado para o moderador, que faz uma análise da inspeção como um todo e re-avalia a qualidade do artefato inspecionado. Ele tem a liberdade de decidir se uma nova inspeção deve ocorrer ou não.

19 Processo Tradicional de Inspeção de Software Variações: O Processo de Inspeção de Humphrey (1989) HUMPHREY (1989), descreve uma variante do processo em que o foco da atividade de preparação individual muda de tentar entender o artefato a ser inspecionado para efetivamente encontrar seus defeitos. Assim, cada um dos inspetores entrega uma lista de discrepâncias para o moderador da inspeção antes da reunião de inspeção se iniciar. O objetivo da reunião passa então a ser discutir as discrepâncias encontradas e classificá-las como defeito ou falso positivo. Inspeções Assíncronas: FTArm (JOHNSON, 1994) Tendo em vista a forma de se realizar inspeções descrita por HUMPHREY, existe proposição de que reuniões de inspeção podem ser evitadas, reduzindo custos e conflitos de alocação de recursos sem sacrificar a eficiência da inspeção. O processo FTArm (acrônimo em inglês para o termo Método de Revisão Técnica Formal Assíncrona ) proposto por JOHNSON (1994) considera este argumento. As atividades do processo FTArm são: planejamento, apresentação, revisão particular, revisão pública, consolidação e reunião. Inspeções de Software Reorganização do Processo de Inspeção por SAUER et al. (2000)

20 Reorganização do Processo de Inspeção Detecção de Defeitos. Cada um dos inspetores selecionados pelo moderador no planejamento realizará uma atividade de detecção de defeitos. A principal tarefa desta atividade consiste em buscar defeitos no documento a ser inspecionado e assim produzir uma lista de discrepâncias. Coleção de Defeitos. O moderador agrupa as listas de discrepâncias dos inspetores. Esta atividade envolve eliminar discrepâncias repetidas (encontradas por mais de um inspetor), mantendo só um registro para cada discrepância. Discriminação de Defeitos. O moderador, o autor do documento e os inspetores discutem as discrepâncias de forma assíncrona. Durante esta discussão, algumas discrepâncias serão classificadas como falso positivo e outras como defeito. Os falso positivos serão descartados e os defeitos serão registrados em uma lista de defeitos, que então será passada para o autor para que a correção possa ocorrer. Processo de Inspeção de Software Gerenciamento (HALLING et al., 2002)

21 Processo de Inspeção de Software Recomendações: (1)Providenciar uma maior integração entre a inspeção e o método de desenvolvimento; (2) Minimizar os encontros e maximizar a assincronicidade nas inspeções; (3) Mudar o foco da detecção de defeitos para melhoria da qualidade dos desenvolvedores; (4) Construir bases de conhecimento baseadas na revisão; (5) Ter como saída a revisão, mas reter o conhecimento da realização desta; (6) Investigar tecnologias de revisão mediadas por computador; (7) Acabar com a limitação do tamanho da equipe de revisores. Prática de Inspeção em Organizações de Software Inspeções em código são as mais comuns 60 Quantidade de Artefatos Inspecionados Requisitos Projeto Código Testes

22 Prática de Inspeção em Organizações de Software Survey (CIOLKOWSKI et al., 2003) indicou que: Inspeções são realizadas de forma pouco sistematizada, pouco conhecimento da área de inspeções de software é utilizado e não exploram o verdadeiro potencial das inspeções (1) Revisões raramente cobrem sistematicamente as fases de desenvolvimento de software. Cerca de 40% das organizações responderam realizar inspeções em requisitos e 30% inspeções em código. (2) Muitas vezes a atividade de detecção de defeitos não é realizada sistematicamente. Cerca de 60% das organizações responderam não conduzir uma atividade de detecção de defeitos regularmente. (3) Organizações raramente utilizam revisões de software no contexto de um programa sistemático de avaliação e melhoria do processo. Mais da metade das empresas participantes do survey respondeu não coletar dados (40%) ou coletar dados e não os utilizar para realizar uma análise (18%). Prática de Inspeção em Organizações de Software Cobertura de defeitos estimada para as organizações participantes do survey. Adaptado de (CIOLKOWSKI et al., 2003) :

23 Técnicas para Identificação de Defeitos em Inspeção de Software Ad-hoc Checklists Técnicas de Leitura Técnica Notação Sistemática? Focada? Melhoria controlada? Adaptável? Treinamento necessário? Ad-Hoc Qualquer Não Não Não Não Não Checklist Qualquer Parcialmente Não Parcialmente Sim Parcialmente Técnicas de Leitura Linguagem Natural Sim Sim Sim Sim Sim Taxonomia para Defeitos: Inspeção de Software Tipo de Defeito Omissão Ambigüidade Definição Informação necessária não incluída Informação passível de ter múltiplas interpretações. Inconsistência Fato Incorreto Informação Estranha Informações conflitantes Informação que não é verdadeira para as condições especificadas. Informação desnecessária

24 Defeitos em Requisitos Exemplo: Sistema de Controle para Postos de Gasolina com auto-atendimento (sem frentista) e serviços de manutenção do veículo Requisito Funcional 5 - Se o pagamento for feito em dinheiro, o caixa é responsável por receber o pagamento e, caso necessário, devolver o troco. Quando o pagamento for feito o caixa fornece essa informação ao sistema. O sistema e a bomba de combustível retornam então para seu estado inicial. Qual o valor da compra? - Para poder completar a transação, o caixa precisa saber o valor da compra. - Informação foi perdida durante a criação dos requisitos. - Esta informação foi omitida da descrição da funcionalidade, logo temos um defeito. Defeitos em Requisitos Requisito Funcional 3 - Se o cliente optar pelo pagamento à vista, ele poderá pagar em dinheiro ou com cartão de crédito. Se escolher pagar em dinheiro, a bomba de combustível deve enviar mensagem instruindo o cliente a procurar o caixa. Se escolher pagar com cartão de crédito, a bomba deve instruir o cliente a inserir o cartão no leitor. Se o cliente não fizer uma opção ou fizer uma opção inválida, o sistema assume o pagamento com cartão de crédito como default. A informação não foi traduzida corretamente. O conhecimento do domínio indica que o pagamento com cartão de crédito não deve ser a opção default, logo temos um defeito.

25 Defeitos em Requisitos Requisito Funcional 2 - Após o abastecimento, a bomba de combustível informa o valor ao sistema. O valor máximo é de R$ 999,99. Requisito Funcional 44 - Se o pagamento for feito com cartão de crédito, o leitor de cartão envia o número do cartão para o sistema. Se o sistema recebe um número? de cartão inválido, então uma mensagem é enviada a bomba para o cliente introduzir o cartão novamente no leitor. Ao receber um número de cartão válido, o número do cartão e o valor da compra são enviados para o sistema da operadora do cartão, e o sistema e a bomba de combustível retornam para o seu estado inicial. O valor máximo de uma compra é de R$1.000,00. A informação foi descrita de forma inconsistente Como o conhecimento de domínio não nos permite saber qual a informação está correta, temos um defeito. Defeitos em Requisitos Requisito Funcional O cliente deve informar o número de sua conta ao caixa, que cadastra a informação no sistema. Se o número de conta for válido, então o número da conta, o valor da compra e uma breve descrição do tipo de transação são registrados (log). Se um número inválido for registrado, uma mensagem de erro é mostrada ao caixa, que deve informar novamente o número. O caixa deve ter também a opção de cancelar a operação. Neste caso, o valor da compra é mostrado novamente juntamente com as opções de pagamento (à vista ou a prazo). A informação pode ser traduzida incorretamente. Que informação é armazenada? O que significa 'tipo de transação'? Combustível/Manutenção? Cartão/Dinheiro?

26 Defeitos em Requisitos Requisito Funcional 7 - Para pagar uma conta mensal, o cliente deve enviar o pagamento junto com o número de sua conta mensal. O caixa seleciona este tipo de pagamento e o sistema envia uma mensagem ao caixa para que o número da conta mensal, o tipo de pagamento e o valor do pagamento sejam informados. Se alguma dessas informações forem inválidas, o sistema retorna para a tela anterior. Se o tipo de pagamento for cartão de crédito, o número do cartão também deve ser informado, e então o recibo do cartão deve ser foto-copiado e armazenado com os outros recibos. Uma informação estranha foi introduzida. Uma informação que, apesar de poder estar correta, pode causar problemas já que não faz parte do sistema. Como isto pode ser testado? Inspeção Ad-hoc Inspetor lê o documento de acordo com sua perspectiva Experiência individual afeta o resultado final: Foco reside na especialidade do inspetor Produtividade individual Difícil garantir que inspetor leu o documento de forma adequada, pois cada um aplica sua própria técnica Não existe garantia de cobertura do documento como um todo Custo/Eficiência (# defeitos/tempo) pode ser adequado quando inspetores possuem muita experiência Aumenta o custo da inspeção

27 Inspeção com Checklist Inspetor segue uma lista de itens indicando características a serem revisadas, porém aplica leitura Ad-hoc para identificar os defeitos Resultado final mais direcionado: Características de qualidade definidas à priori Produtividade individual Difícil garantir que inspetor leu o documento de forma adequada, mesmo tendo sido definidas as características de qualidade a se procurar Cobertura do documento relacionada aos itens do Checklist Custo/Eficiência depende do Checklist e dos inspetores Checklist pode ser adaptado ou construído para capturar uma determinada especificidade Inspeção com Checklist: Exemplo Sugestão de um Checklist para Inspeção de Requisitos No Item para Verificação SIM NÃO 1 Cada requisito está descrito com clareza, concisão e sem ambigüidade? 2 Existem requisitos implícitos? 3 Os requisitos exibem a distinção clara entre funções, dados e restrições? 4 Existem requisitos conflitantes? 5 As restrições e dependências foram claramente descritas? 6 Existem requisitos que contêm algum nível desnecessário de detalhe do projeto? 7 Os requisitos definem todos os usuários do sistema? 8 Os requisitos definem todas as informações a serem apresentadas aos usuários? 9 Os requisitos descrevem as respostas do sistema ao usuário devido às condições de erro? 10 Existem situações não tratadas pelos requisitos que precisam ser consideradas? 11 Os requisitos não funcionais (tais como tempo de resposta, armazenamento de dados, etc.) foram definidos? 12 O requisito é testável? Se não, que informação está faltando para torná-lo testável? 13 O documento contém realmente toda a informação prometida em sua introdução?

28 Inspeção com Checklist: Exemplo de Resultado Formulário para Relato de Defeito Tempo de Aplicação do Checklist (minutos): 120 Identificação do Inspetor: J.J. XPT Nome do Projeto: UseCase Tool Documento: Documento de requisitos da ferramenta de construção de Casos de Uso para utilização na Técnica de Leitura PBR. Data: Dez/2005 Defeito No. Página No. Req. No. Tipo Defeito Descrição 1 2 RF 8 Omissão Falta uma forma de consulta aos elementos do modelo presentes na ferramenta. Exemplo: estrutura em árvore ou diretórios 2 Omissão Os requisitos não abordam tratamento de erros 3 3 RF 11/12 Ambigüidade Não está muito clara a diferença entre os requisitos 11 e RF 5 Ambigüidade Usa-se no documento os termos participante e ator para descrever a mesma coisa. 5 Omissão Falta descrição de como será a interface com o usuário e sua navegação. ARQCHECK (Abordagem para avaliação de documentos arquiteturais baseada em checklist) Objetivo: Identificar defeitos em documentos arquiteturais, aumentando a qualidade do software Características Principais: Avaliação da consistência do documento arquitetural Avaliação do atendimentos dos requisitos pela a arquitetura do software Avaliação das abordagens utilizadas para atender os requisitos de qualidade na arquitetura do software Produtos Gerados: Lista de defeitos arquiteturais identificados Referência: BARCELOS, R.F. (2006) Uma abordagem para inspeção de documentos arquiteturais baseada em checklist, Dissertação de Mestrado, PESC/COPPE, UFRJ. Utilizada no contexto de: Garantia da qualidade de arquiteturas de software Material de ArqCheck produzido por Rafael Barcelos

29 Revisão de modelos arquiteturais: como avaliar se a arquitetura satisfaz aos requisitos? ArqCheck: Documento arquitetural Possuir as seguintes características (IEEE 1471) Identificar os elementos arquiteturais e a forma como estão organizados Descrever o papel de cada elemento Identificar como cada requisito é atendido através da arquitetura Rastreabilidade requisitos-elementos arquiteturais Representar o software através de diferentes perspectivas Uso de visões arquiteturais.

30 ArqCheck: modelos arquiteturais ArqCheck: Processo de Inspeção Composto pelas seguintes atividades Planejamento; Apresentação; Detecção; Reunião de inspeção; Retrabalho; Continuação Alterações nas atividades Planejamento Sub-atividades de configuração Executadas para selecionar somente os itens aplicáveis» Depende das características do documento arquitetura» Depende da avaliação a ser realizada Detecção Definição da ordem de utilização dos itens A identificação de defeitos de consistência influencia na identificação de defeitos relacionados ao atendimento dos requisitos

31 ArqCheck: Papéis e perfis da equipe de inspeção Necessita dos três papéis tradicionais Moderador Autor do documento Inspetor Alocar mais de um inspetor com conhecimentos diferentes Aumenta a cobertura de defeitos encontrados ArqCheck: Taxonomia de defeitos Adaptação da taxonomia de [SHULL, 1998] Omissão Quando um elemento arquitetural necessário para o atendimento a um requisito não foi definido; Ambigüidade Quando a forma como os elementos arquiteturais ou suas responsabilidades foram definidos dificulta ou impossibilita o atendimento a um requisito de qualidade. Quando elementos descritos em visões distintas possuem o mesmo nome, mas responsabilidades diferentes (Homônimo); Inconsistência Quando elementos descritos em visões distintas possuem mesma responsabilidade, mas nomes distintos (Sinônimo); Quando um elemento arquitetural presente em diagramas das demais visões não foi definido no diagrama avaliado; Quando a representação não condiz com a semântica estabelecida pela abordagem de documentação. Quando um elemento arquitetural é definido com responsabilidades distintas em duas ou mais visões. Quando um elemento é representado de maneira diferente em duas visões. Fato Incorreto Quando um elemento não foi descrito ou representado de forma correta Quando não é possível mapear um elemento arquitetural para algum elemento descrito em outra visão. Informação Estranha Quando não é possível determinar o papel de um elemento arquitetural ou de uma de suas responsabilidades no atendimento aos requisitos especificados.

32 ArqCheck: checklist de avaliação Baseado Técnica de leitura orientada a objetos (OORT s) [TRAVASSOS et al. 2002] Rastreabilidade da informação Táticas Arquiteturais Principais propriedades Extensível Alguns itens são dependentes da representação arquitetural Adição de novas características a serem avaliadas Configurável Características do documento arquitetural Objetivos da avaliação ArqCheck: checklist de avaliação

33 ArqCheck: checklist de avaliação ArqCheck: Itens que avaliam a consistência do documento Objetivo Avaliar se os diferentes elementos arquiteturais e seus relacionamentos foram corretamente representados nos diversos diagramas Artefatos envolvidos Documento arquitetural

34 ArqCheck: checklist de avaliação ArqCheck: Itens que avaliam o atendimento aos requisitos Objetivo Avaliar se todos os requisitos especificados foram corretamente atendidos na arquitetura Artefatos envolvidos Documento de requisitos Documento arquitetural

35 ArqCheck: checklist de avaliação ArqCheck: Itens de avaliação da abordagem de atendimento aos requisitos de qualidade Objetivo Avaliar se a abordagem utilizada para atender aos requisitos de qualidade está correta Artefatos envolvidos Documento arquitetural Documento de requisito Características específicas a esses itens Sub-grupos de itens que avaliam o atendimento a determinado tipo de requisito de qualidade Desempenho Disponibilidade Modificabilidade Segurança Testabilidade Usabilidade Checklist fornece informações adicionais para auxiliar avaliação

36 ArqCheck: Itens de avaliação da abordagem de atendimento aos requisitos de qualidade Requisito avaliado ArqCheck: Itens de avaliação da abordagem de atendimento aos requisitos de qualidade Cenário de qualidade

37 ArqCheck: Itens de avaliação da abordagem de atendimento aos requisitos de qualidade Guia de identificação de contexto ArqCheck: Itens de avaliação da abordagem de atendimento aos requisitos de qualidade Itens de avaliação relacionados

38 ArqCheck: lições aprendidas Resultados observados em estudos experimentais: Indicação da viabilidade de ArqCheck Os itens do checklist ajudam a identificar defeitos Inspetores consideraram ArqCheck útil para apoiar a identificação de defeitos Inspetores identificaram necessidade de treinamento para aplicação do checklist Configuração adequada do checklist auxilia a reduzir o número de falso positivos Apresentou eficiência superior quando comparada a técnica ad-hoc em caso real de desenvolvimento: ArqCheck: 7 defeitos/hora inspeção ad-hoc: 1,25 defeitos/hora inspeção Técnicas de Leitura Motivação: desenvolvedores são treinados para escrever artefatos de software, mas raramente possuem habilidades para revisá-lo desenvolvedores confiam em técnicas ad-hoc e não seguem um procedimento bem definido Objetivos: fornecer um conjunto de instruções a serem seguidas pelos revisores para que os defeitos sejam detectados introduzir um formalismo que garanta que o procedimento possa ser seguido e repetido, possibilitando a melhoria contínua do processo de revisão reduzir a influência humana nos resultados (aproximar de uma atividade de Engenharia)

39 Técnicas de Leitura O que é uma técnica de leitura? Um conjunto de instruções concretas dado ao leitor que diz como ler e o que procurar num produto de software Mais especificamente, leitura de software é a análise individual de um artefato de software ex., requisitos, projeto, código, planos de teste para alcançar a compreensão necessária para uma tarefa em particular ex., identificação de defeitos, reutilização, manutenção Técnicas de leitura Definem uma abordagem para ser ajustada Não existe apenas um conjunto de técnicas de leitura Técnicas de leitura são - específicas ao documento e notação - direcionadas a um objetivo - ajustáveis para o projeto e o ambiente - definidas de forma procedural - focadas para fornecer uma cobertura particular do documento - experimentalmente verificadas para ser eficaz quando de sua utilização nos métodos existentes, tais como inspeções - O framework de técnicas de leitura fornece uma forma de incorporar várias melhores práticas num ambiente de inspeção

40 Aprimorando as Práticas de Leitura 3 princípios que tem sido úteis para tornar inspeções eficazes: Dar a cada revisor um único e particular foco (ou perspectiva) para o documento sob revisão Tentar fazer a revisão de um documento uma atividade ativa (invés de passiva) Articular as características de qualidade importantes Perspectivas para Inspeção Associe perspectivas diferentes para inspetores diferentes cada inspetor de uma equipe de inspeção lê um documento de acordo com uma perspectiva em particular. Benefícios: define as responsabilidades de cada inspetor minimiza a sobreposição entre as responsabilidades dos inspetores maximiza a união dos defeitos encontrados Cobertura Ad hoc Cobertura com Téc. Leitura

41 Uso de Técnicas de Leitura na Inspeção de Software Artefato Software Como conduzir uma inspeção com técnicas de leitura? Organizador 1 Planejamento Form. Planejamento Técnicas de Leitura Inspector Deteção 2 Form. Relato Defeito Papéis moderador inspetor autor Coleção 3 Form. Relato Defeito Atividades Produtos autor Correção 4 Form. Relato Defeito Artefato Software Corrigido Utilizando em Métodos de Inspeção Reunião da Equipe Correção pelo Autor Revisão Individual Revisor registra defeitos Revisor registra defeitos Reunião nominal : listas são agregadas Equipe se reune para montar a lista final de consenso Revisor registra defeitos Estilo de reunião Fagan: questões servem como lembretes enquanto a equipe discute a identificação de defeitos em conjunto

42 Comparação de técnicas de inspeção para especificação de requisitos Que abordagens para leitura estão disponíveis para identificação de defeitos em documentos de requisitos? Ad-hoc, Checklists, Técnicas de leitura ajustadas (PBR/DBR) Técnica Notação Requisitos Sistemática? Focada? Melhoria Controlada? Ajustável? Treinamento necessário? Ad hoc qualquer Não Não Não Não Não Check list qualquer Parcial Não Parcialmente Sim Parcial DBR SCR (formal Sim Sim Sim Sim Sim language) PBR Linguagem Natural Sim Sim Sim Sim Sim Leitura Baseada em Perspectiva (PBR) se baseiam no fato de existirem diferentes papéis durante o processo de desenvolvimento do software; provê um conjunto de instruções de acordo com o papel do consumidor de um artefato (usuário, projetista ou testador); Procurando Defeitos: Documento de requisitos atenderá às necessidades de seus futuros consumidores? Informações contidas no documento permitem que uma representação correta do sistema seja feita? Quando isto não acontece, uma discrepância é identificada e deve, então, ser categorizada. SRS Casos de Uso Casos de Teste Diagramas de Projeto

43 Leitura Baseada em Perspectiva (PBR) Taxonomia para os Defeitos: Tipo de Defeito Omissão Ambigüidade Inconsistência Fato Incorreto Informação Estranha Definição Informação necessária não incluída no documentos Informação passível de ter múltiplas interpretações. Informações conflitantes Informação que não é verdadeira para as condições especificadas. Informação desnecessária PBR: Histórico de Desenvolvimento Primeira experiência no Goddard Space Flight Center/NASA. Estudos realizados com estudantes e profissionais em diferentes universidades: UMCP, UMBC, Uni-Kl, NTU, Uni- Lund, COPPE/UFRJ, USP-São Carlos, UFSCar, Tutoriais apresentados em workshops e conferências: ICSE, NASA s Software Engineering Workshop Adaptada para uso industrial e treinamento na Allianz Life Insurance, Bosch Telecom, Robert Bosch GmbH, CPqD, RioSoft, LENS-COPPE

44 Leitura Baseada em Perspectiva (PBR) Fatos: inspeções com PBR encontram 35% mais defeitos que revisões ad-hoc (BOEHM e BASILI,2001) a técnica ajuda a manter os inspetores focados durante toda a fase de identificação de discrepâncias PBR evita que os inspetores realizem inspeções superficiais a técnica altera (aprimora) o padrão de raciocínio dos inspetores Leitura Baseada em Perspectiva (PBR) Cada inspetor recebe um cenário que guia o seu trabalho. uma descrição procedural das atividades e questões que guiam o inspetor na utilização do documento sendo inspecionado. Cada cenário consiste de duas partes: -construir um modelo a partir do documento sendo revisado de forma a aumentar o entendimento; -responder questões sobre o modelo criado, focando em problemas de interesse para a organização.

45 Leitura Baseada em Perspectiva (PBR) Para escolher os cenários em PBR: 1. Escolha a perspectiva sob a qual o documento deve ser revisado. 2. Escolha o modelo a ser construído que faça sentido para cada perspectiva. 3. Escolha os tipos de defeitos de interesse para a organização, utilizando esta informação para questionar o modelo construído. Perspectivas estão associadas aos modelos Tipos de defeito de interesse Procedimento baseado na construção de modelos e perguntas adaptáveis. Leitura Baseada em Perspectiva (PBR) Cada inspetor no time de inspeção lê o documento sob uma determinada perspectiva. Benefícios: Foca a responsabilidade de cada inspetor; Minimiza a sobreposição de responsabilidades; Maximiza a cobertura dos defeitos.

46 Aplicação de PBR O nível de detalhamento da técnica pode variar: Utilização pela primeira vez: baixo nível de detalhe para garantir o apoio Adaptáveis para níveis de experiência: Novatos: mais detalhes Especialistas: só precisam da perspectiva geral Uso em diferentes modelos de ciclo de vida: No modelo espiral, por exemplo, as primeiras iterações teriam um nível de detalhe menor já que a informação inicial é definida num nível mais alto de abstração. PBR: complementaridade das perspectivas Documentos de requisitos com 30 defeitos plantados Resultados observados em dois estudos experimentais no Goddard Space Flight Center/NASA.

47 Utilização dos Dados Métricas e observações baseadas no uso permitem o aprimoramento contínuo. possibilidade de inclusão de novas perspectivas de interesse para a organização. possibilidade de troca da combinação das perspectivas. Ex: Se é esperada a predominância de um certo tipo de defeito, inclua mais revisores utilizando a perspectiva relevante. possibilidade de alteração da taxonomia de defeitos. possibilidade de alteração no nível de detalhamento. PBR: Perspectiva do Usuário Na perspectiva do usuário, os requisitos devem capturar adequadamente as funcionalidades necessárias para o sistema. Representa a visão do usuário do sistema (e não uma visão de implementação!) Facilita a comunicação entre os projetistas e os usuários do sistema. Ajuda a validar se o sistema sendo descrito irá funcionar da maneira esperada pelos usuários.

48 PBR: Perspectiva do Usuário Escolha uma representação para funcionalidades: caso de uso é baseado num cenário descritivo de como o usuário interage com o sistema. Identifica os eventos que ocorrem, descrevendo a resposta do sistema. descreve um conjunto particular de funcionalidades do sistema ao modelar o "diálogo que o usuário tem com o sistema. é um fluxo de eventos completo, tomado a partir da perspectiva de um uso particular do sistema. "consumido" nos estágios subseqüentes do ciclo de vida. Objetivo: tomados em conjunto, todos os casos de uso constituem todas as possibilidades de utilização do sistema. PBR: Perspectiva do Usuário A elaboração de casos de uso auxiliam na identificação de defeitos em requisitos Casos de uso provêem uma representação diferente para uma mesma funcionalidade descrita em requisitos escritos em linguagem natural Hipóteses para a detecção de defeitos: Se os requisitos escritos em linguagem natural são bem especificados, devemos ser capazes de convertê-los em casos de uso de uma maneira relativamente fácil Se existem problemas com os requisitos, a criação de casos de uso claros e completos pode não ser possível. Estes problemas provavelmente também causarão dificuldades na construção de outros artefatos que se baseiam nos requisitos, como o projeto ou código O processo de construção de casos de uso pode ser usado como um auxílio na identificação de defeitos.

49 PBR: Perspectiva do Usuário Primeiro componente principal: participante entidades do ambiente, externos ao sistema. interagem com o sistema para alcançar alguma funcionalidade. também conhecidos como atores. Participantes podem ser: usuários humanos, outros sistemas, organizações externas, dispositivos externos, etc, que interagem com o sistema. Alguns participantes iniciam eventos; outros interagem com o sistema como resultado de outros eventos. Quando usuários estão envolvidos: um participante é um papel (isto é, uma maneira característica de interagir com o sistema) e não uma pessoa específica. PBR: Perspectiva do Usuário Segundo componente principal: funcionalidade Mais do que qualquer outra coisa, os casos de uso preocupam-se em descrever o comportamento do sistema. Problema: é muito difícil especificar uma definição exata para a maneira intuitiva com que normalmente descrevemos as funcionalidades do sistema. Há muita variação na forma como os conceitos dos casos de uso são aplicados para descrever o sistema: muito descuido em algumas situações e rigor excessivo em outras. Funcionalidade devem ser descritas em dois níveis: funções do produto (Que características o produto tem? Que funções específicas ele pode realizar?) cenários de uso (Para que os clientes podem usar o sistema?)

50 PBR: Perspectiva do Usuário Passo 1: Instrução Geral: Leia todos os requisitos uma vez, identificando os participantes envolvidos. Instruções Específicas: Quais grupos de usuários utilizam o sistema para executar suas tarefas? Que grupos de usuários são necessários pelo sistema para executar suas funções? Estas funções podem ser as principais, ou mesmo as secundárias tais como manutenção e administração. Quais são os sistemas externos que utilizam o sistema visando executar as tarefas? Quais são os sistemas externos que são gerenciados ou de outra forma usados pelo sistema visando executar suas tarefas? Quais são os grupos de usuários ou sistemas externos que enviam informação para o sistema? Quais são os sistemas externos ou grupos de usuários que recebem informação do sistema? PBR: Perspectiva do Usuário Passo 1: Questões: Q1.1 Um mesmo participante está sendo descrito por múltiplos termos nos requisitos? Q1.2 A descrição de como o sistema interage com um participante está inconsistente com a descrição do participante? Os requisitos estão confusos ou inconsistentes sobre esta interação? Está situação está omitindo alguma parte importante da funcionalidade como um todo? Q1.3 Existem participantes necessários que foram omitidos? Isto é, o sistema precisa interagir com outro sistema, ou dispositivo de hardware, ou um tipo de usuário que não está descrito? Q1.4 Existe algum sistema externo ou classe de usuários descrito nos requisitos que realmente não interage com o sistema?

51 PBR: Perspectiva do Usuário PBR: Perspectiva do Usuário Passo 2: Instrução Geral: Descreva as funcionalidades do sistema. Instruções Específicas: Identifique o conjunto de funcionalidades que o sistema deve ser capaz de executar. Isto é, que atividades os requisitos explicitamente descrevem que o sistema deve executar? (Ex. apresentar um registro do banco de dados, imprimir um relatório, criar e apresentar um gráfico) Registre a funcionalidade no formulário A. Agora considere como um usuário do sistema o visualizará. Ele ou ela provavelmente não está preocupado com as atividades individuais que o sistema executa, mas ao invés disto pensa em como pode usar o sistema para alcançar algum objetivo (Ex. adicionar informação em alguma base de dados, calcular um pagamento, visualizar a situação atual de uma conta). Estes objetivos do usuário serão definidos como os casos de uso para o sistema. Para cada caso de uso, utilize uma nova cópia do formulário B. Decida qual das atividades descritas no formulário A estão envolvidas neste caso de uso e anote-as no formulário B. Faça então um esboço, do ponto de vista do usuário, dos passos que são necessários para alcançar o objetivo utilize setas para identificar o fluxo de controle do sistema ( Primeiro está funcionalidade acontece, então esta ). Utilize setas duplas para representar o momento onde o fluxo de controle pode se dividir. Lembre-se de incluir situações de exceção no caso de uso. Verifique os requisitos funcionais apropriados para assegurar que você tem os detalhes corretos do processamento e fluxo de controle. Para cada caso de uso que você criar, lembre-se de relacionar que classe(s) de participante(s) utilizariam a funcionalidade (as classes de participantes já devem estar registradas na lista de participantes do formulário A), bem como as ações que iniciam a funcionalidade (Ex. selecionando a opção 2 do menu principal deve disparar o caso de uso para apagar os registros da base de dados) Existem espaços específicos para registrar estas informações no formulário B. Finalmente, dê ao caso de uso um nome descritivo que represente a funcionalidade que ele descreve e associe a ele um número para referência futura.

52 PBR: Perspectiva do Usuário Passo 2: Questões: Q2.1 As condições de início para cada caso de uso estão especificadas num nível de detalhe apropriado? Q2.2 A(s) classe(s) de participante(s) que utilizam a funcionalidade estão descritas e são corretas e apropriadas? Q2.3 Existe alguma funcionalidade do sistema que deveria ser incluída no caso de uso, mas que está descrita com detalhe insuficiente ou omitida dos requisitos? Q2.4 O sistema está suficientemente descrito de forma que você possa entender que atividades são necessárias para o usuário executar o objetivo do caso de uso? Esta combinação de atividades faz sentido, baseado na descrição geral do sistema e em seu conhecimento do domínio? A descrição permite mais de uma interpretação de como o sistema alcança seu objetivo? Q2.5 Os requisitos estão omitindo casos de uso que você sente serem necessários, de acordo com seu conhecimento do domínio ou descrição geral? PBR: Perspectiva do Usuário

53 PBR: Perspectiva do Usuário PBR: Perspectiva do Usuário Passo 3: Instrução Geral: Conferir os participantes com todos os casos de uso que eles estejam envolvidos. Instruções Específicas: Lembre-se que se dois participantes estão envolvidos em todos os mesmos casos de uso, eles podem representar um único ator e poderiam ser combinados. Utilize a coluna Envolvido em que caso de uso? do formulário A para conferir os participantes com os casos de uso apropriados.

54 PBR: Perspectiva do Usuário Passo 2: Questões: Q3.1 Está claro a partir dos requisitos quais participantes estão envolvidos em quais casos de uso? Q3.2 Baseado nos requisitos gerais e em seu conhecimento do domínio, cada participante foi relacionado a todos os casos de uso relevantes? Q3.3 Os participantes envolvidos nos casos de uso estão incompatíveis com a descrição do participante? Q3.4 Participantes necessários foram omitidos? (Ex. existem casos de uso que requerem informação que não pode ser obtida de alguma das fontes descritas nos requisitos)? PBR: Perspectiva do Usuário

55 PBR: Formulário de Discrepâncias Equipe: J.J. XPT Tempo aplicando PBR (in minutes): 1h e 35min No. Defeito Pag. Linha # Req. # Categoria de Defeito Breve descrição do defeito 1 2 Seção Seção Seção 2.1 Inconsistência Informação Estranha Ambiguidade O número máximo de vagas está definido com 34, enquanto que o Requisito Funcional 10 define como 59 O botão Mensal da Unidade de Controle não é utilizado em nenhum outro ponto do documento O item Entrada / Motorista sem uma vaga reservada no estacionamento, número 2, deveria referenciar o botão como Botão de Pedido, conforme definição na seção Seção 2.1 Omissão O item Entrada / Motorista com uma vaga reservada no estacionamento, número 2, não descreve o que caracteriza um cartão inválido 5 4 Seção 2.1 Omissão O item Entrada / Motorista com uma vaga reservada no estacionamento, número 3, não descreve o que fazer quando um cartão inválido for utilizado 6 4 Seção 2.1 Fato Incorreto O item Saída, número 3, deveria referenciar o sistema como responsável por procurar o ingresso, e não o leitor de cartão PBR: Perspectiva do Projetista Na perspectiva do projetista, os requisitos devem capturar adequadamente as classes e objetos necessários para o sistema Representa a visão do projetista do sistema (alto nível e não uma visão de implementação!) Facilita a comunicação entre os projetistas e os programadores do sistema. Ajuda a avaliar se o documento de requisitos possui informação suficiente que permitirá o projeto e construção do software.

56 PBR: Perspectiva do Projetista Escolha uma representação para funcionalidades: Diagrama de classes UML é baseado nas classes (atributos, comportamentos) e seus relacionamentos especificados através do documentos de requisitos. descreve a estrutura estática dos conceitos envolvidos no software e as responsabilidades de cada um. é uma representação da abstração utilizada para classificação e passo inicial para se definir a estratégia de fatoração que será utilizada (modularidade). "consumido" nos estágios subseqüentes do ciclo de vida (arquitetura, implementação, testes,...). Objetivo: representados em conjunto, classes (atributos, comportamentos) e seus relacionamentos conseguem mostrar os conceitos relevantes para se desenvolver o software PBR: Perspectiva do Projetista A elaboração de diagramas de classe auxiliam na identificação de defeitos em requisitos Diagramas de Classe provêem uma representação em nível de abstração diferente para os conceitos envolvidos no software e contidos em requisitos escritos em linguagem natural Hipóteses para a detecção de defeitos: Se os requisitos escritos em linguagem natural são bem especificados, devemos ser capazes de convertê-los em diagramas de classe de uma maneira relativamente fácil Se existem problemas com os requisitos, a criação de diagramas de classe claros e completos pode não ser possível. Estes problemas provavelmente também causarão dificuldades na construção de outros artefatos que se baseiam nos requisitos, como os modelos arquiteturais, planejamento de testes ou mesmo código O processo de construção de diagramas de classe pode ser usado como um auxílio na identificação de defeitos.

57 OO-PBR (Apoio à Revisão de Requisitos de Software) A técnica OO-PBR visa a apoiar: Revisão de documentos de requisitos de software. Construção de modelos iniciais de projeto OO. A aplicação de OO-PBR pode ser útil na garantia da qualidade do software OO, ao: Permitir ao engenheiro de software obter um entendimento satisfatório sobre o problema descrito nos requisitos. Possibilitar a remoção eficiente de defeitos críticos no início do desenvolvimento diminuindo o custo total do projeto. Representar um ponto de partida para o desenvolvimento de um sistema OO de qualidade. Referência: MAFRA, S.N. (2006) Leitura Baseada em Perspectiva: A Perspectiva do Projetista Orientada a Objetos, Dissertação de Mestrado, PESC/COPPE, UFRJ. Utilizada no contexto de: Garantia da qualidade de requisitos de software. Material de OO-PBR produzido por Sômulo Mafra OO-PBR (Apoio à Revisão de Requisitos de Software)

58 Perspectiva do Projetista: Técnica OO-PBR OO-PBR divide-se em 3 componentes: Instruções Descreve o propósito da técnica t descrevendo como a mesma deve ser aplicada. Passos Passos para a construção do modelo de projeto de alto nível OO. Cada passo pode conter questões relacionadas à detecção de defeitos nos requisitos, decorrente da execução do passo. Questões Contém m questões voltadas para a identificação de defeitos no documento de requisitos inspecionado, uma vez que todos os passos foram conduzidos. Passo 1 Técnica OO-PBR Identificar Classes e Atributos. Passo 2 Identificar Relacionamentos e suas multiplicidades. Passo 3 identificar Funcionalidades do Sistema, e Identificar Classes Candidatas a satisfazerem-na. Passo 4 identificar como as classes candidatas irão satisfazer as funcionalidades do sistema através s de responsabilidades. Pode envolver a colaboração com outras classes candidatas.

59 Aplicando OO-PBR Domínio da Aplicação Transporte Aéreo A (STATR) Objetivo do Sistema O STATR deve automatizar o planejamento de vôo e o transporte de cargas e passageiros. Passo 1 Aplicando OO-PBR Objetivo: Identificar Classes e Atributos.

60 Aplicando OO-PBR Passo 1 Os vôos podem ser comerciais ou fretados. Cada vôo é descrito por um número, n e por um local de origem e um local de destino. Além m disso, por questões referentes ao DAC (Departamento de Aviação Civil), cada número n deve ser composto por 4 algarismos. Um vôo pode ser suspenso, replanejado, ou estar ativo, em um determinado momento. Aplicando OO-PBR Passo 1 Os vôos podem ser comerciais ou fretados.. Cada vôo é descrito por um número,, e por um local de origem e um local de destino.. Além m disso, por questões referentes ao DAC (Departamento de Aviação Civil), cada número n deve ser composto por 4 algarismos.. Um vôo pode ser suspenso, replanejado,, ou estar ativo,, em um determinado momento. Nomes marcados: vôo, comercial, fretado, número, n origem, destino, DAC, algarismos, replanejado, ativo, suspenso, momento.

61 Aplicando OO-PBR Passo 1 Os vôos podem ser comerciais ou fretados.. Cada vôo é descrito por um número,, e por um local de origem e um local de destino.. Além m disso, por questões referentes ao DAC (Departamento de Aviação Civil), cada número n deve ser composto por 4 algarismos.. Um vôo pode ser suspenso, replanejado,, ou estar ativo,, em um determinado momento. Nomes marcados: vôo, comercial, fretado, número, n origem, destino, DAC, algarismos, replanejado, ativo, suspenso, momento. Aplicando OO-PBR Passo 1 Os vôos podem ser comerciais ou fretados.. Cada vôo é descrito por um número,, e por um local de origem e um local de destino.. Além m disso, por questões referentes ao DAC (Departamento de Aviação Civil), cada número n deve ser composto por 4 algarismos.. Um vôo pode ser suspenso, replanejado,, ou estar ativo,, em um determinado momento. Nomes marcados: vôo, comercial, fretado, número, n origem, destino, DAC, algarismos, replanejado, ativo, suspenso, momento. Nomes selecionados: vôo, comercial, fretado, número, n origem, destino, replanejado, ativo, suspenso.

62 Aplicando OO-PBR Passo 1 Formulário rio de Classes Classe: Atributos Nome Tipo Valores Nome Tipo Valores Responsabilidades Aplicando OO-PBR Passo 1 Formulário rio de Classes Classe: Vôo Atributos Nome Estado Tipo Estado Valores Replanejado, suspenso e ativo. Nome Numero Tipo Numérico Valores Responsabilidades

63 Aplicando OO-PBR Passo 1 Nomes selecionados: vôo, comercial, fretado, número, n origem, destino, replanejado, ativo, suspenso. Estado pode ser: Replanejado Suspenso ativo OO-PBR: questões passo 1 As classes extraídas representam conceitos envolvidos no domínio da aplicação? Caso negativo, conceitos irrelevantes podem estar especificados nos requisitos, caracterizando uma possível informação estranha. Todos os conceitos extraídos que sejam pertinentes ao domínio da aplicação estão descritos numa seção de Glossário ou outra seção similar? Caso negativo, definições importantes para o domínio da aplicação podem não estar detalhadas adequadamente, caracterizando uma possível omissão. Há presença de sinônimos (mais de um nome representando um mesmo conceito) ou homônimos (um nome representando mais de um conceito)? Caso positivo, reporte uma ambigüidade. A descrição de algum conceito contradiz outros conceitos? Caso positivo, reporte uma inconsistência. As informações presentes nos requisitos permitem a você estipular os tipos básicos para todos os atributos das classes? Caso contrário, reporte uma discrepância do tipo omissão. As informações presentes no documento permitem a você estipular todos os possíveis valores para os atributos que representam faixa de valores (Ex.: estados de um objeto)? Caso contrário, reporte uma omissão.

64 Passo 2 Aplicando OO-PBR Objetivo: Identificar Relacionamentos e suas multiplicidades. Aplicando OO-PBR Passo 2 Os vôos podem ser comerciais ou fretados. Cada vôo é descrito por um número, n e por um local de origem e um local de destino. Além m disso, por questões referentes ao DAC (Departamento de Aviação Civil), cada número n deve ser composto por 4 algarismos. Um vôo pode ser suspenso, replanejado, ou estar ativo, em um determinado momento.

65 Aplicando OO-PBR Passo 2 Os vôos podem ser comerciais ou fretados. Cada vôo é descrito por um número, n e por um local de origem e um local de destino. Além m disso, por questões referentes ao DAC (Departamento de Aviação Civil), cada número n deve ser composto por 4 algarismos. Um vôo pode ser suspenso, replanejado, ou estar ativo, em um determinado momento. Aplicando OO-PBR Passo 2 Os vôos podem ser comerciais ou fretados. Cada vôo é descrito por um número, e por um local de origem e um local de destino. Além m disso, por questões referentes ao DAC (Departamento de Aviação Civil), cada número n deve ser composto por 4 algarismos. Um vôo pode ser suspenso, replanejado, ou estar ativo, em um determinado momento.

66 Aplicando OO-PBR Passo 2 Os vôos podem ser comerciais ou fretados. Cada vôo é descrito por um número, e por um local de origem e um local de destino. Além m disso, por questões referentes ao DAC (Departamento de Aviação Civil), cada número n deve ser composto por 4 algarismos. Um vôo pode ser suspenso, replanejado, ou estar ativo, em um determinado momento. OO-PBR: questões passo 2 As informações presentes nos requisitos permitem a você estipular a multiplicidade dos relacionamentos envolvidos? Caso contrário, reporte uma discrepância do tipo omissão.

67 Passo 3 Objetivo: Aplicando OO-PBR identificar Funcionalidades do Sistema, e Identificar classes candidatas a satisfazerem-na. Aplicando OO-PBR Passo 3 RF12 - O avião deve iniciar procedimento de pouso quando a cabine de controle assim o permitir. Quando o avião pousar, a cabine de controle deve tornar a pista livre. Caso o avião arremeta, a cabine de controle deve replanejar o pouso do avião.

68 Aplicando OO-PBR Passo 3 RF12 - O avião deve iniciar procedimento de pouso quando a cabine de controle assim o permitir. Quando o avião pousar, a cabine de controle deve tornar a pista livre. Caso o avião arremeta, a cabine de controle deve replanejar o pouso do avião. Nome da Funcionalidade: Gerenciar Pouso de Avião. Aplicando OO-PBR Passo 3 RF12 - O avião deve iniciar procedimento de pouso quando a cabine de controle assim o permitir. Quando o avião pousar, a cabine de controle deve tornar a pista livre. Caso o avião arremeta, a cabine de controle deve replanejar o pouso do avião. Nome da Funcionalidade: Gerenciar Pouso de Avião.

69 Aplicando OO-PBR Passo 3 RF12 - O avião deve iniciar procedimento de pouso quando a cabine de controle assim o permitir. Quando o avião pousar, a cabine de controle deve tornar a pista livre. Caso o avião arremeta, a cabine de controle deve replanejar o pouso do avião. Nome da Funcionalidade: Gerenciar Pouso de Avião. Classes candidatas: Avião, Cabine de Controle e Pista de Pouso. Aplicando OO-PBR Passo 3 Formulário rio de Funcionalidades Funcionalidade: Dados de Entrada: Casos de Sucesso: Casos de Erro: Classes Candidatas:

70 Aplicando OO-PBR Passo 3 Formulário rio de Funcionalidades Funcionalidade: Dados de Entrada: Gerenciar Pouso de Avião N/A Casos de Sucesso: Pista livre Casos de Erro: Cabine replanejar pouso Classes Candidatas: Avião, Cabine de Controle e Pista de Pouso OO-PBR: questões passo 3 Os requisitos descrevem passo-a-passo como o sistema deve proceder para executar as funcionalidades? Caso as funcionalidades não estejam devidamente especificadas, reporte uma omissão. Os requisitos descrevem os casos de sucesso e de erro para cada funcionalidade extraída? Caso negativo, reporte uma omissão. Caso as funcionalidades possuam restrições, o documento descreve como essas restrições devem ser verificadas? Ex.: Na funcionalidade O sistema deve permitir que o gerente visualize... é descrito como o sistema pode verificar se a pessoa executando a operação é um gerente? Caso negativo, reporte uma omissão. Todos os dados requeridos para a execução de cada funcionalidade estão devidamente especificados? Por exemplo, numa sentença gerar relatório, os requisitos descrevem quais são os dados que devem constar no relatório? Caso os dados não estejam especificados reporte uma omissão. Ao preencher uma funcionalidade, as informações requeridas pelo Formulário de Funcionalidades encontram-se dispersas pelo documento de requisitos? Caso positivo, reporte uma localização incorreta. As sentenças estão descritas de forma objetiva? Por exemplo, Sistema valida... ao invés de Sistema checa se.... A primeira opção descreve um resultado positivo; a segunda opção, menos objetiva, deixa a saída em aberto. Caso a sentença não esteja descrita de forma objetiva, aumenta a possibilidade de diferentes interpretações, o que caracteriza uma ambigüidade. Há presença de requisitos que não devem ser implementados na solução final? Ex.: Após emitir o recibo, o documento deve ser fotocopiado e enviado ao.... Apesar de correto, a presença do requisito é irrelevante nos requisitos de software, pois se trata de um requisito de sistema, a ser satisfeito através de uma operação manual. Um desenvolvedor, dependendo da interpretação adotada, poderia automatizar a função de fotocópia na solução final. Caso positivo, reporte uma informação estranha.

71 Passo 4 Objetivo: Aplicando OO-PBR identificar como as classes candidatas irão satisfazer as funcionalidades do sistema através s de responsabilidades. Pode envolver a colaboração com outras classes candidatas. Aplicando OO-PBR Passo 4 RF12 - O avião deve iniciar procedimento de pouso quando a cabine de controle assim o permitir. Quando o avião pousar, a cabine de controle deve tornar a pista livre. Nome da Funcionalidade: Gerenciar Pouso de Avião. Classes candidatas: Avião, Cabine de Controle e Pista de Pouso.

72 Aplicando OO-PBR Passo 4 RF12 - O avião deve iniciar procedimento de pouso quando a cabine de controle assim o permitir. Quando o avião pousar, a cabine de controle deve tornar a pista livre. Nome da Funcionalidade: Gerenciar Pouso de Avião. Classes candidatas: Avião, Cabine de Controle e Pista de Pouso. Aplicando OO-PBR Passo 4 RF12 - O avião deve iniciar procedimento de pouso quando a cabine de controle assim o permitir.. Quando o avião pousar, a cabine de controle deve tornar a pista livre. Nome da Funcionalidade: Gerenciar Pouso de Avião. Classes candidatas: Avião, Cabine de Controle e Pista de Pouso.

73 Aplicando OO-PBR Passo 4 RF12 - O avião deve iniciar procedimento de pouso quando a cabine de controle assim o permitir. Quando o avião pousar, a cabine de controle deve tornar a pista livre. Nome da Funcionalidade: Gerenciar Pouso de Avião. Classes candidatas: Avião, Cabine de Controle e Pista de Pouso. Aplicando OO-PBR Passo 4 Formulário rio de Classes Classe: Atributos Nome Tipo Valores Responsabilidades

74 Aplicando OO-PBR Passo 4 Formulário rio de Classes Classe: Avião Atributos Nome Capacidade Tipo Numérico Valores N/A Responsabilidades Iniciar procedimento de vôo. Aplicando OO-PBR Passo 4 RF12 - O avião deve iniciar procedimento de pouso quando a cabine de controle assim o permitir.. Quando o avião pousar, a cabine de controle deve tornar a pista livre. Nome da Funcionalidade: Gerenciar Pouso de Avião. Classes candidatas: Avião, Cabine de Controle e Pista de Pouso.

75 OO-PBR: questões passo 4 As responsabilidades de cada classe podem ser satisfeitas através dos atributos e responsabilidades contidos na classe, ou através das responsabilidades de suas classes relacionadas? Caso negativo, provavelmente há uma omissão na descrição dos conceitos ou das funcionalidades descritas nos requisitos. As responsabilidades atribuídas a uma classe levam em consideração os atributos da classe que sejam pertinentes ao propósito das responsabilidades? Por exemplo, suponha uma classe Usuário contendo um atributo chamado endereço. Caso uma funcionalidade Cadastrar Usuário, relacionada à classe Usuário, não indicar o preenchimento do endereço, provavelmente há uma omissão na descrição da funcionalidade. As responsabilidades de uma classe descrevem como, e sob quais circunstâncias, um objeto da classe pode alterar o valor de seus estados? Caso contrário, reporte uma omissão. Analisando cada classe, os tipos especificados para os atributos requeridos por uma determinada responsabilidade estão consistentes com o objetivo desta responsabilidade? Caso negativo, provavelmente a descrição dos conceitos que deram origem às classes está inconsistente com a descrição das funcionalidades. OO-PBR: questões finais Os requisitos estão descritos com termos vagos? (Ex.: sincronizar, fácil de integrar, rápido retorno etc). Caso positivo, há uma falta de detalhamento desses termos, caracterizando uma discrepância do tipo omissão. Há presença de advérbios? (Ex.: provavelmente, periodicamente etc). Caso positivo, os requisitos podem estar descritos sem precisão, caracterizando uma omissão. Há sentenças onde o ponto referenciado não é claro? (Ex.: O sistema controla o aquecimento. Ele deve ser... A que se referencia o pronome ele? A aquecimento ou a sistema?). Caso positivo, reporte uma ambigüidade. Os requisitos estão descritos de forma a permitir testá-los?(ex.:...o tempo de resposta deve ser rápido.... Quão rápido deve ser o tempo de resposta?). Caso negativo, reporte uma omissão. Os requisitos estão agrupados nas devidas seções (os requisitos presentes na seção de requisitos funcionais são realmente requisitos funcionais?)? Caso negativo, reporte uma discrepância do tipo localização incorreta. Os requisitos descrevem diferentes papéis (caixa, gerente etc)? Caso positivo, verifique se os requisitos descrevem quais funcionalidades devem ser executadas por quais papéis. Caso os requisitos descrevam explicitamente que uma determinada funcionalidade deve ser executada por um determinado papel, mas não especifique como o papel deve executar a funcionalidade, reporte uma omissão. As classes, seus relacionamentos e suas responsabilidades fazem sentido sobre o que você conhece do domínio da aplicação ou sobre o que você entendeu dos requisitos? (Ex.: na sentença O sistema deve emitir um recibo contendo a descrição do produto e seu valor total. Uma possível omissão é a data em que o recibo foi emitido, que não foi descrita nos requisitos). Caso negativo, a situação caracteriza um fato incorreto.

76 OO-PBR: formulário de discrepâncias Revisor #: Data: Início (hh:mm): Duração (em minutos): Utilize este formulário para relatar eventuais discrepâncias que você identificar durante a inspeção de requisitos utilizando OO-PBR. Ao identificar uma discrepância, indique: o número da discrepância, o tipo da discrepância (vide abreviações abaixo), o local em que foi identificada a discrepância (Ex.: RF12, Pág. 5, Glossário etc), o horário em que a discrepância foi identificada (Ex.: 16:55), o passo da técnica que levou à identificação da discrepância, caso pertinente (Ex.: Passo 1, Q3.3 etc), e uma descrição da discrepância, sucinta e concisa, mas que permita ao autor do documento corrigi-la. Para o relato do tipo da discrepância, utilize as seguintes abreviações: O - Omissão IE - Informação Estranha A - Ambigüidade IN - Inconsistência LI - Localização Incorreta FI - Fato Incorreto Num. Tipo Local. Hora (hh:mm) Passo Descrição da Discrepância Técnicas de Leitura Orientada a Objetos OORT s Aplicam-se à inspeção de projeto Orientado a Objetos: família de técnicas de leitura que pode ser utilizada para ler artefatos de projeto OO de alto nível (descritos em UML) contra: 1. Eles mesmos, garantindo consistência 2. Requisitos e casos de uso, garantindo rastreabilidade dentro de um domínio com o objetivo de encontrar defeitos entre eles. Representa uma abordagem de leitura baseada em defeito

77 Loan State Diagram Late A Lender : Specified Lender Receive Monthly Report monthly_report( lender, loans, borrowers) receive a monthly report Fanny May : Loan Arranger monthly report informing payment on time [ payment time <= due time ] Good verify_report() monthly report informing payment on time monthly report informing late payment [ payment time <= due time ] [ payment time > due time + 10 ] monthly report informing late payment [ due time < payment time < due time + 10 ] monthly report informing late payment [ payment time > due time + 10 ] identify_report_format() lende r : look_for_a_lender(lender) update(lender) new_lender(name,contact, phone_number) look_for_a_loan(loan) update_loan(lender, borrower) new_loan(lender, borrowers) Default Loan : Loan look_for_a_ update_ new_ Borrower : Borrower OORT s: As diferentes visões em projeto OO Um projeto simples consiste de vários diagramas inter-relacionados, utilizando diversas notações para expressar diferentes visões da mesma informação. Monthly Report Lender name : text id : text contact : text phone_number : number 1..* Bundle active time period : date profit : number estimated risk : number total : number loan analyst : id_number discount_rate : number investor_name : text date_sold : date Specified Lender Receive Reports Request Investor Investment Request Generate Reports Fanny May Loan Analyst 1..* risk() calculate_profit() Borrower Loan cost() 1 name : text amount : number 0..1 id : number interest rate : number risk : number settlement data : date status : text term : date status : text Loan Arranger risk() 1..* original_value : number set_status_good() 1..* principal_original : number rec_monthly_report() set_status_late() inv_request() set_status_default() risk() generate reports() borrower_status() set_status_default() identify_report_format() set_status() set_status_late() verify_report() set_status_good() look_for_a_lender() look_for_a_loan() discount_rate() identify_loan_by_criteria() borrowers() manually_select_loans() principal_remaining() optimize_bundle() calculate_new_bundle() identify_asked_report() aggregate_bundles() aggregate_loans() aggregate_borrowers() Variable_Rate Loan aggregate_lenders() Fixed_Rate Loan format_report() principal_remaining : number show_report() risk() risk() principal_remaining() principal_remaing() Loan-Arranger Requirements Specification Jan. 8, 1999 Background Loan Arranger Classes Description Class name: Fixed_Rate Loan Banks generate income in many ways, often by borrowing money from their depositors Category: Logical View at a low interest rate, and then lending that same money at a higher interest rate in the Documentation: A fixed rate loan has the same interest rate over the entire term of the mortgage form of bank loans. However, property loans, such as mortgages, typically have terms of 15, 25 or even 30 years. For example, suppose that you purchase a $150,000 house with External Documents: Export Control: Public a $50,000 down payment and borrow a $100,000 mortgage from National Bank for Cardinality: n thirty years at 5% interest. That means that National Bank gives you $100,000 to pay the Hierarchy: balance on your house, and you pay National Bank back at a rate of 5% per year over a Superclasses: Loan Public Interface: period of thirty years. You must pay back both principal and interest. That is, the initial Operations: principal, $100,000, is paid back in 360 installments (once a month for 30 years), with risk principal_remaining interest on the unpaid balance. In this case the monthly payment is $ Although the income from interest on these loans is lucrative, the loans tie up money for a long State machine: No Concurrency: Sequential time, preventing the banks from using their money for other transactions. Consequently, Persistence: Persistent the banks often sell their loans to consolidating organizations such as Fannie Mae and Operation name: risk Freddie Mac, taking less long-term profit in exchange for freeing the capital for use in Public member of: Fixed_Rate Loan other ways. Return Class: float Documentation: take the average of the risks' sum of all borrowers related to this loan if the average risk is less than 1 round up to 1 else if the average risk is less than 100 round up to the nearest integer otherwise round down to 100 Concurrency: Sequential Inspeção de Projeto: OORT s Object-Oriented Reading Techniques (OORT s) revisam projetos OO de alto nível para assegurar que: desenvolvedores compreendam o problema completamente antes de tentar definir uma solução o máximo possível de defeitos seja identificado e removido ainda em alto nível de abstração defeitos são muito mais difíceis e custosos de acertar se propagarem para o projeto de baixo nível ou mesmo para o código.

78 Inspeção de Projeto: OORT s História tem sido objeto de uma série de estudos experimentais com estudantes e profissionais que verificaram sua viabilidade e significância dos defeitos encontrados em diferentes universidades e centros de pesquisa tais como University of Maryland, University of Southern California, Fraunhofer Center-MD/USA, COPPE/UFRJ, USP-São Carlos, UFSCar, NTNU/Noruega Aplicadas para inspeção em projeto real na Oracle Brasil (grupo de engenharia de qualidade) e Ericsson (Noruega) com resultados satisfatórios. Adaptadas e estendidas para apoiarem as atividades de inspeção em um processo de desenvolvimento de software orientado a objetos na UFSCar Atualmente vem sendo aprimoradas (através de experimentação) e apoio automatizado está sendo construído na COPPE/UFRJ para auxiliar sua aplicação OORT s: Artefatos Alvo Especificação de Requisitos Descrição dos Requisitos Casos de Uso Projeto de Alto Nível Diagrama de Classes Descrição das Classes Diagrama Transição de Estados Diagramas de Interação Leitura Vertical Leitura Horizontal (Seqüência)

79 OORT s: qualidade articulada A taxonomia genérica de defeitos instanciada para projeto OO de alto nível. Classificação Defeito Omissão Fato Incorreto Inconsistência Ambigüidade Informação Estranha Descrição Um ou mais diagramas de projeto que deveria conter algum conceito dos requisitos gerais ou do documento de requisitos não contêm uma representação para o conceito. Um diagrama de projeto contêm uma representação errada de um conceito descrito nos requisitos gerais ou no documento de requisitos. Uma representação de um conceito em um diagrama de projeto não concorda com uma representação do mesmo conceito no mesmo ou outro diagrama de projeto. Uma representação de um conceito no projeto não está clara, e poderia levar o usuário do documento (projetista de baixo nível, desenvolvedor, etc.) a interpretar de forma diferente ou não entender o significado do conceito. O projeto inclui informação que, enquanto talvez verdadeira, não se aplica a este problema e não deveria estar incluída no projeto. OORT s: Leitura Horizontal Assegura que todos os artefatos de projeto representam o mesmo sistema Podem ser aplicadas como base de atividades de verificação Projeto contêm visões complementares da informação Estática (diagrama de classes) Dinâmica (diagramas de interação) Não é óbvio como comparar estas diferentes perspectivas

80 OORTs: exemplo de leitura horizontal OORT's Leitura Horizontal v3.0 Leitura 1 Diagramas de Seqüência x Classes Objetivo: Verificar que um diagrama de classes para um sistema descreve as classes e seus relacionamentos de forma que os comportamentos especificados nos diagramas de seqüência estão capturados corretamente. Para fazer isto, você verificará primeiro que as classes e objetos especificados no diagrama de seqüência aparecem no diagrama de classes. Então, você verificará que o diagrama de classe descreve os relacionamentos, comportamentos e condições que capturam a dinâmica dos serviços como estão descritos no diagrama de seqüência. Entradas para o processo: 1. Um diagrama de classes (possivelmente dividido em pacotes) que descreve as classes de um sistema e como elas estão associadas. 2. Diagramas de seqüência que descrevem as classes, objetos, e possivelmente atores de um sistema e como eles colaboram para capturar os serviços do sistema. I. Pegue um diagrama de seqüência e leia-o para entender que serviços do sistema estão descritos e como o sistema deveria implementar estes serviços. ENTRADAS: Diagrama de Seqüência (DS). SAÍDAS: Objetos do Sistema (marcados em azul no DS); Serviços do Sistema (marcados em verde no DS); Condições nos serviços (marcadas em amarelo no DS). A. Para cada diagrama de seqüência, sublinhe os objetos do sistema e classes, e quaisquer atores, com uma caneta azul. B. Sublinhe a informação trocada entre objetos (as setas horizontais) com uma caneta verde. Considere se esta informação representa mensagens ou serviços do sistema. Se a informação trocada está muito detalhada, para um nível de mensagens, você deverá abstrair várias mensagens juntas para entender que serviços elas estão fornecendo em conjunto. O exemplo 2 fornece uma ilustração de mensagens sendo abstraídas como serviços. Anote no diagrama de seqüência descrevendo estes serviços, e sublinhe-os também em verde.... Formulário de Relato de Discrepância para Leitura Horizontal Nome do Projeto: Sistema de Controle de Estacionamento Equipe: J.J.XPT Técnica de Leitura Horizontal: Diagramas de Sequência x Classes Início da Inspeção: 15:40h Data: 04/08/2003 Documentos que estão sendo lidos [preencha o nome e o tipo]: Documento 1: Diagrama de Classes Documento 2: Diagrama de Sequência Motorista Sem Ingresso Reservado Entra no Estacionamento Tipo de Conceito: (AC) ator (AT) atributo (BE) comportamento (CA) cardinalidade (CO) condição (CR) restrição (DA) dado (IN) herança (ME) mensagem (OB) objeto/classe (RE) relacionamento (RO) papel Disc. # Tipo de Discrepância (Tipo Disc.): Severidade (Sev.): (1) presente no Documento 1 mas não no Documento 2 (NS) Não é sério. Mas precisa verificar este (2) presente no Documento 2 mas não no Documento 1 documento. (3) presente em ambos os documentos mas inconsistente ou (IN) Esta discrepância invalida esta parte do ambiguo documento. Verifique ambos os documentos. (4) presente em ambos os documentos mas usando uma (SE) Sério. Não é possível continuar a leitura deste representação ou notação incorreta documento. Ele deveria ser reorganizado. (5) presente em ambos os documentos mas representa informação estranha (6) faltando em ambos os documentos [explique abaixo] Preencha a tabela com as discrepâncias que encontrou: Tipo de Conceit o Nome Tipo Disc. Sev. Comentários 01 AC Máquina de Ingresso 2 NS 02 ME FornecerIngresso 2 NS 03 RE 2 NS Falta relacionamento entre Máquina de Ingresso e Estacionamento no diagrama de classes 04 CA Portão 1 IN Um Estacionamento possui vários Portões e um Portão está vinculado a um Estacionamento

81 OORT s: Leitura Vertical Asseguram que os artefatos de projeto representam o sistema descrito pelos requisitos e casos de uso Podem ser aplicadas como base de atividades de validação Comparam documentos de diferentes fases do ciclo de vida Nível de abstração e detalhe são diferentes Exploram a rastreabilidade semântica entre os documentos OORTs: exemplo de leitura vertical

82 OORTs: qualidade articulada Verificação semântica Esta classe pode significativamente encapsular todos estes atributos? Os atributos estão associados com os tipos básicos possíveis ou viáveis? Está faltando atributo em algum dos documentos, ou existe algum atributo desnecessário incluído em algum dos documentos? OORTs: Metáfora de utilização A. Para cada diagrama de seqüência, sublinhe os objetos do sistema e classes, e quaisquer atores, com uma caneta azul Unidade de Controle PagarIngresso (number) Espera_Troco() Parking Garage : Estacionamento Tempo < 1 seg Criar (Hora, Número) IngressoCom um : Ingresso_Diário

83 OORTs: Metáfora de utilização A. Para cada diagrama de seqüência, sublinhe os objetos do sistema e classes, e quaisquer atores, com uma caneta azul Unidade de Controle PagarIngresso (number) Espera_Troco() Parking Garage : Estacionamento Tempo < 1 seg Criar (Hora, Número) IngressoCom um : Ingresso_Diário OORTs: Metáfora de utilização B. Sublinhe a informação trocada entre os objetos (as setas horizontais) com uma caneta verde. Considere se esta informação representa mensagens ou serviços do sistema. Se a informação trocada está muito detalhada, para um nível de mensagens, você deverá abstrair várias mensagens juntas para que serviços elas estão oferecendo em conjunto. Unidade de Controle PagarIngresso (number) Espera_Troco() Parking Garage : Estacionamento Tempo < 1 seg Criar (Hora, Número) IngressoCom um : Ingresso_Diário

84 OORTs: Metáfora de utilização B. Sublinhe a informação trocada entre os objetos (as setas horizontais) com uma caneta verde. Considere se esta informação representa mensagens ou serviços do sistema. Se a informação trocada está muito detalhada, para um nível de mensagens, você deverá abstrair várias mensagens juntas para que serviços elas estão oferecendo em conjunto. Unidade de Controle PagarIngresso (number) Espera_Troco() Parking Garage : Estacionamento Tempo < 1 seg Criar (Hora, Número) IngressoCom um : Ingresso_Diário OORTs: Metáfora de utilização C. Circule qualquer das seguintes restrições nas mensagens e serviços, com uma caneta amarela: restrições no número de classes/objetos que uma mensagem poderia enviar, restrições nos valores globais de um atributo, dependências entre dados, ou restrições de tempo que podem afetar o estado de um objeto. Circule também quaisquer condições que determinam sob que circunstâncias uma mensagem pode ser enviada. Unidade de Controle PagarIngresso (number) Espera_Troco() Parking Garage : Estacionamento Tempo < 1 seg Criar (Hora, Número) IngressoCom um : Ingresso_Diário

85 OORTs: Metáfora de utilização C. Circule qualquer das seguintes restrições nas mensagens e serviços, com uma caneta amarela: restrições no número de classes/objetos que uma mensagem poderia enviar, restrições nos valores globais de um atributo, dependências entre dados, ou restrições de tempo que podem afetar o estado de um objeto. Circule também quaisquer condições que determinam sob que circunstâncias uma mensagem pode ser enviada. Unidade de Controle PagarIngresso (number) Espera_Troco() Parking Garage : Estacionamento Tempo < 1 seg Criar (Hora, Número) IngressoCom um : Ingresso_Diário Estacionamento k : Integer r : Integer Ingresso o : Integer Leitor_Cartão Número : Integer localização : String ValidarIngresso() 0..n 0..1 SolicitarIngresso() 1 n Éválido() InserirIngresso() IngressoRetirado() MotoristaSaiu() IngressoMensalNovo() Destruir() PagarIngresso() VerificarVagasDisponíveis() 1..n Unidade de Controle PagarIngresso (number) Espera_Troco() Parking Garage : Estacionamento Tempo < 1 seg Criar (Hora, Número) IngressoCom um : Ingresso_Diário 1 Portão Localização : String Abrir_Portão() Fechar_Portão() Ingresso_Mensal data_compra : Date Éválido() Criar() Ingresso_Diário Hora_pagamento : String Valor_pago : Float Éválido() Criar() MotoristaSaiu()

86 Estacionamento k : Integer r : Integer Ingresso o : Integer Leitor_Cartão Número : Integer localização : String ValidarIngresso() 0..n 0..1 SolicitarIngresso() 1 n Éválido() InserirIngresso() IngressoRetirado() MotoristaSaiu() IngressoMensalNovo() Destruir() PagarIngresso() VerificarVagasDisponíveis() 1..n Unidade de Controle? PagarIngresso (number) Espera_Troco() Parking Garage : Estacionamento Tempo < 1 seg Criar (Hora, Número) IngressoCom um : Ingresso_Diário 1 Portão Localização : String Abrir_Portão() Fechar_Portão() Ingresso_Mensal data_compra : Date Éválido() Criar() Ingresso_Diário Hora_pagamento : String Valor_pago : Float Éválido() Criar() MotoristaSaiu() Estacionamento k : Integer r : Integer Ingresso o : Integer Leitor_Cartão Número : Integer localização : String ValidarIngresso() 0..n 0..1 SolicitarIngresso() 1 n Éválido() InserirIngresso() IngressoRetirado() MotoristaSaiu() IngressoMensalNovo() Destruir() PagarIngresso() VerificarVagasDisponíveis() 1..n Unidade de Controle PagarIngresso (number) Espera_Troco() Parking Garage : Estacionamento Tempo < 1 seg Criar (Hora, Número) IngressoCom um : Ingresso_Diário 1 Portão Localização : String Abrir_Portão() Fechar_Portão() Ingresso_Mensal data_compra : Date Éválido() Criar() Ingresso_Diário Hora_pagamento : String Valor_pago : Float Éválido() Criar() MotoristaSaiu()

87 Estacionamento k : Integer r : Integer Ingresso o : Integer Leitor_Cartão Número : Integer localização : String ValidarIngresso() 0..n 0..1 SolicitarIngresso() 1 n Éválido() InserirIngresso() IngressoRetirado() MotoristaSaiu() IngressoMensalNovo() Destruir() PagarIngresso() VerificarVagasDisponíveis() 1..n Unidade de Controle PagarIngresso (number) Espera_Troco() Parking Garage : Estacionamento Tempo < 1 seg Criar (Hora, Número) IngressoCom um : Ingresso_Diário 1 Portão Localização : String Abrir_Portão() Fechar_Portão() Ingresso_Mensal data_compra : Date Éválido() Criar() Ingresso_Diário Hora_pagamento : String Valor_pago : Float Éválido() Criar() MotoristaSaiu()

88 Formulário de Relato de Discrepância para Leitura Horizontal Nome do Projeto: Sistema de Controle de Estacionamento Equipe: J.J.XPT Técnica de Leitura Horizontal: Diagramas de Sequência x Classes Início da Inspeção: 15:40h Data: 04/08/2003 Documentos que estão sendo lidos [preencha o nome e o tipo]: Documento 1: Diagrama de Classes Documento 2: Diagrama de Sequência Motorista Sem Ingresso Reservado Entra no Estacionamento Tipo de Conceito: (AC) ator (AT) atributo (BE) comportamento (CA) cardinalidade (CO) condição (CR) restrição (DA) dado (IN) herança (ME) mensagem (OB) objeto/classe (RE) relacionamento (RO) papel Tipo de Discrepância (Tipo Disc.): Severidade (Sev.): (1) presente no Documento 1 mas não no Documento 2 (2) presente no Documento 2 mas não no Documento 1 (3) presente em ambos os documentos mas inconsistente ou ambiguo (4) presente em ambos os documentos mas usando uma representação ou notação incorreta (5) presente em ambos os documentos mas representa informação estranha (6) faltando em ambos os documentos [explique abaixo] (NS) Não é sério. Mas precisa verificar este documento. (IN) Esta discrepância invalida esta parte do documento. Verifique ambos os documentos. (SE) Sério. Não é possível continuar a leitura deste documento. Ele deveria ser reorganizado. Preencha a tabela com as discrepâncias que encontrou: Disc.# Tipo de Conceito Nome Tipo Disc. Sev. Comentários 01 AC Máquina de Ingresso 2 NS 02 ME FornecerIngresso 2 NS 03 RE 2 NS Falta relacionamento entre Máquina de Ingresso e Estacionamento no diagrama de classes 04 CA Portão 1 IN Um Estacionamento possui vários Portões e um Portão está vinculado a um Estacionamento OORTs: Conclusões Resultados baseado em estudos experimentais: Técnicas são viáveis Técnicas ajudam a identificar defeitos Leitura horizontal encontra mais defeitos de INCONSISTÊNCIA e AMBIGUIDADE Leitura vertical encontra mais defeitos de OMISSÃO e FATO INCORRETO Conhecimento técnico OO mais importante que conhecimento do domínio para sua aplicação Seu uso continuado aprimora qualidade dos produtos Técnicas já utilizadas na indústria Embora sua aplicação manual seja perfeitamente viável, Ferramenta de Apoio (Orion) disponível Incorporação à Infra-estrutura para inspeção ISPIS e futuramente ao Ambiente TABA (

89 Apoio Ferramental para Inspeção de Software Apoio Ferramental: 16 Ferramentas foram analisadas em (MACDONALD e MILLER, 1999). GRIP (HALLING et al., 2001) e IBIS (LANUBILE e MALLARDO, 2002) tem sido utilizados em estudos experimentais e publicações recentes. Muitas destas ferramentas têm como foco a fase de detecção de defeitos e a inspeção de um tipo de artefato específico. Não exploram efetivamente o conhecimento da área de inspeções de software, o conhecimento gerado em (ADAMS, 1999) (BIFFL et al., 2003) (CARVER, 2003) e (VITHARANA e RAMAMURTHY, 2003) não é utilizado em nenhuma das ferramentas. Apenas IBIS (disponível em automatiza a reorganização do processo de inspeção proposta em (SAUER et al., 2000). Nenhuma das ferramentas analisadas permite a integração a outras ferramentas para a detecção de defeitos... Ferramenta ICICLE Apoio Ferramental para Inspeção de Software Processo Processo Tradicional (Fagan, 1976) Tipo de Reunião Síncrona InspeQ Processo Próprio Síncrona CSI CSRS Scrutiny Processo de Humphrey (HUMPHREY, 1989) FTArm (JOHNSON, 1994) Processo da BULL HB Information Systems, variante do processo tradicional. Síncrona Assíncrona Síncrona WIT Processo Próprio Assíncrona Técnicas Técnica Própria Inspeção por Fases (com checklists específicas) Ad-hoc Ad-hoc e checklists Ad-hoc Ad-hoc e checklists Artefatos Código C e C++ descritos textualmente descritos textualmente descritos textualmente descritos textualmente descritos em HTML Equipes Distribuídas GRIP Processo Próprio Assíncrona Ad-hoc Todos os tipos Sim IBIS Sauer et al. (2000) Assíncrona Ad-hoc e checklists Todos os tipos Não Não Não Sim Sim Sim Sim

90

91

92

93 ISPIS (Infra-estrutura de Apoio ao Processo de Inspeção de Software) Objetivo: Apoiar o planejamento, controle e a execução do processo de inspeção de software. Características Principais: Coordena e apóia a execução de inspeções, podendo ser com reuniões assíncronas: Menor custo e mesma eficiência Permite que inspeções sejam realizadas por equipes geograficamente distribuídas Apóia tomadas de decisão com base em conhecimento adquirido através de estudos experimentais e dados históricos da organização Pode ser utilizada para inspecionar qualquer artefato de software Possui um mecanismo de integração com ferramentas que apóiam a detecção de defeitos em artefatos específicos Tem sido utilizada em inspeções de requisitos e projeto reais na indústria. Ano de Desenvolvimento (1ª versão): 2004.

94 ISPIS - Decisões de Projeto Extensão da ferramenta de workflow PatternFlow (KALINOWSKI, 2001) Plataforma de Desenvolvimento Internacionalização Apresentação Customizada ISPIS - Arquitetura (KALINOWSKI et al., 2004)

95 ISPIS - Apoio ao Planejamento Tarefas do Planejamento Definição do Contexto. Seleção dos Inspetores. Distribuição de Material. Apoio à tomada de decisão da seleção de inspetores Utilizando sua caracterização. Hipóteses fundamentadas de CARVER (2003) são utilizadas para fornecer uma lista ordenada dos inspetores mais indicados de acordo com o contexto da inspeção e sua caracterização. Critério de ordenação é o número de características desejadas para a inspeção em questão que o inspetor possui. Utilizando dados históricos sobre o desempenho do inspetor em inspeções passadas sobre o mesmo tipo de artefato.

96

97 ISPIS - Apoio à Detecção Tarefas da Detecção Ver Contexto da Inspeção. Ver Documentos. Relatar discrepâncias. Apoio à aplicação de inspeções ad-hoc. Apoio à técnicas específicas, disponibilizando ferramentas externas integradas à infraestrutura.

98 ISPIS - Apoio à Coleção Tarefas da Coleção Ver Contexto da Inspeção. Ver Documentos. Juntar Listas de Discrepâncias dos Inspetores, removendo duplicatas. Utiliza os resultados do estudo experimental apresentado em (LANUBILE e MALLARDO, 2003) Discriminação deve ser restrita a discrepâncias encontradas por apenas um inspetor. Discrepâncias repetidas podem ser identificadas pelo moderador como defeito para que sejam diretamente encaminhadas para a atividade de retrabalho.

99

100 ISPIS - Apoio à Discriminação Tarefas da Discriminação Ver Contexto da Inspeção. Ver Documentos. Discutir Discrepâncias, classificando-as como defeito ou falso positivo. Possibilita uma discussão assíncrona Utiliza resultados de um estudo experimental (VITHARANA e RAMAMURTHY, 2003) O anonimato dos participantes ajuda na classificação correta das discrepâncias.

101 ISPIS - Apoio ao Retrabalho Tarefas do Retrabalho Ver Contexto da Inspeção. Ver os Documentos. Produzir Formulário de Correção dos Defeitos. Anexar a versão corrigida dos Documentos.

102 ISPIS - Apoio à Continuação Tarefas da Continuação Ver Contexto da Inspeção. Ver Documentos Originais e Corrigidos. Ver Formulário de Correção de Defeitos. Decidir Reinspeção. Apóia a decisão de realizar uma nova inspeção ou não com os seguintes dados: Estimativas da cobertura de defeitos para a inspeção atual e para a próxima inspeção Número de Defeitos é estimado utilizando o Weighted Average of Individual Offsets (BIFFL et al., 2003). Cobertura de defeitos da próxima inspeção é estimada utilizando o Modelo ILM (ADAMS, 1999) Experimentalmente avaliado em (BIFFL e GUTJAHR, 2002). Dado histórico do número médio de defeitos encontrados em inspeções passadas sobre o mesmo tipo de artefato. Aplicação da diretriz de FAGAN (1976), re-inspecionar se tiver 5% a mais de defeitos do que a média neste mesmo tipo de artefato. Técnicas de Estimativa Número de Defeitos do Documento Pode ser estimado utilizando uma técnica de estimativa subjetiva: Adaptado de (Biffl et al., 2003)

103 Técnicas de Estimativa Eficiência na re-inspeção Pode ser estimado utilizando como base a eficiência na inspeção atual: Modelo ILM (Adams, 1999). Adaptado de (Biffl e Gutjahr, 2003).

104 ISPIS - Apoio à Gerencia do Processo Seguindo a proposta de gerenciamento ativo de inspeções (HALLING et al., 2002), ISPIS: Auxilia a tomada de decisões no planejamento com base na avaliação de inspeções passadas. Permite o monitoramento das inspeções. Permite avaliações pós-processo visando entender a relação entre processo de inspeção, inspetores e artefato inspecionado. Definição da estrutura do processo está encapsulada em ISPIS, facilitando mudanças para fins experimentais Apoio Ferramental para Inspeção de Software Ferramenta Processo Tipo de Reunião Técnicas Artefatos Equipes Distribuídas IBIS Sauer et al. (2000) Assíncrona Ad-hoc e checklists Todos os tipos Sim ISPIS Sauer et al. (2000) Assíncrona Ad-hoc e demais técnicas através da integração de ferramentas externas. Todos os tipos Sim

105 Inspeção de Software: Apoio Automatizado Infra-estrutura ISPIS: apóia (por default) inspeção ad-hoc, mas permite integração de outras ferramentas através de mecanismos baseados em XML mapeados através de xmapper PBR tool: apóia a aplicação de PBR, perspectiva usuário, contando ainda com ferramenta para detalhamento de casos de uso (UseCase Tool) Orion Tool: apóia a aplicação de OORTs Guia o inspetor na execução da tarefa conforme especificação original da técnica PBR-usuário PBR Tool Mediçãode tempo nãoinvasiva.

106 Permite ao inspetor ver/colar o conteúdo do requisito na descrição da discrepância PBR Tool Fornece ajuda na taxonomia de defeitos Modelo de Relatório de Caso de Uso PBR Tool

107 Formulário de Relato de Discrepância PBR Tool PBR Tool Arquivo de Saída XML Momento da identificação da Discrepância Tarefa executada quando a discrepância foi identificada Tempo Total de Inspeção

108 Apoio a aplicação de OORTs Características Básicas de Orion Tool Divisão dos Conceitos Processo Atividade Tarefa

109 Características Básicas de Orion Tool Máquinas de Estados Possíveis estados de uma inspeção Possíveis estados de uma atividade ou tarefa Arquitetura de Orion Tool