SIMPROS /01/2008

Transcrição

1 PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO SUL PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO Um Modelo para Avaliação da Qualidade da Tradução de Requisitos para Casos de Uso Ms. Fabiana Zaffalon Ferreira Rocha Prof. Dr. Ricardo Melo Bastos Prof. Dr. Marcelo Hideki Yamaguti Ms. Elisa Cerri e Cerri Dezembro / 2007 Trabalho desenvolvido no convênio PUCRS/Dell Computadores do Brasil Ltda. com recursos da Lei 8.248/91 Agenda Contexto Identificação do Problema Método de Pesquisa Referencial Teórico Abordagens para Avaliação da Qualidade Modelo de Integração Modelo para Avaliação da Qualidade da Tradução entre Requisitos e Casos de Uso Avaliação do Modelo Considerações Contribuições Trabalhos Futuros 1

2 Contexto Atributos / Métricas de qualidade Identificação, descoberta de requisitos Análise e negociação de requisitos Documentação de requisitos SRS Qualidade Especificação UC Validação de requisitos Identificação do Problema A existência de lacunas identificadas nos modelos de qualidade de requisitos: Atributos de qualidade. Avaliação da qualidade dos requisitos ou dos casos de uso. Encontrou-se poucos trabalhos na literatura envolvendo a geração de casos de uso a partir do SRS. 2

3 Método de Pesquisa ETAPA 1 Base Teórica Especificação de requisitos e casos de uso, métricas e atributos de qualidade ETAPA 3 Identificação dos elementos do SRS que se relacionam com os elementos da especificação de casos de usos Seleção e adaptação dos atributos e métricas ETAPA 2 Estudo do SRS e especificação de casos de uso Modelo de Integração ETAPA 4 Desenvolvimento do Modelo Aplicação do modelo desenvolvido Avaliação do modelo Referencial Teórico 3

4 Requisitos de Software Segundo IEEE Standard Glossary of Software Engineering i Terminology : Uma condição ou capacidade necessária para um usuário resolver um problema ou alcançar um objetivo (...). Requisitos Funcionais Requisitos Não funcionais Qualidade de Requisitos A qualidade de requisito de software é o primeiro passo para a qualidade do software. Medidos através de atributos. 4

5 SRS Software Requirements Specification SOMMERVILLE conceitua SRS como a atividade de traduzir as informações coletadas durante a atividade de análise em um documento que defina um conjunto de requisitos. Segundo Padrão IEEE Std 830 um SRS de qualidade tem que ser: Correto Não-ambíguo Completo Consistente Ordenado Verificável Modificável Rastreável SRS Software Requirements Specification (cont.) Estrutura do SRS - IEEE Std

6 Casos de Uso Segundo COCKBURN, um caso de uso é uma técnica de modelagem usada para descrever o que um novo sistema deve fazer. De acordo com JACOBSON, os casos de uso têm por objetivo: decidir e descrever os requisitos funcionais do sistema; fornecer uma descrição clara e consistente do que o sistema deve fazer; Especificação de Casos de Uso A especificação de um Caso de Uso deve considerar: como e quando o Caso de Uso inicia ou termina; as interações com os atores envolvidos; as seqüências normais de execução; as seqüências alternativas ou de exceção. 6

7 Especificação de Casos de Uso Template de especificação de casos de uso GQM Goal Question Metric É uma abordagem orientada a objetivos para medição de produtos e processos de Engenharia de Software. Objetivo: auxiliar a decidir como as medições devem ser feitas e como devem ser utilizadas. As métricas são derivadas com base nas questões, definidas a partir dos objetivos. Fases: Planejamento, Definição, Coleta de Dados e Interpretação. 7

8 Abordagens para Avaliação da Qualidade Ferramentas que avaliam a qualidade dos requisitos: QuARS (Quality Analyzer for Requirements Specification) e ARM (Automated Requirement Measurement) Analisam gramaticalmente o requisito em orações escritas em LN e apontam os erros. Visam reduzir defeitos lingüísticos indicando palavras ambíguas ou incompletas de um ponto de vista léxico. Modelo de Qualidade: Ambigüidade, Consistência e Completude. TUCCA (Técnica de Leitura para Apoiar a Construção de Modelos de Casos de Uso e a Análise de Documentos de Requisitos) it Composta de duas técnicas de leitura: AGRT (Actor Goal Reading Technique) URT (Use Case Reading Technique) Especificação de Requisitos: IEEE Std 830 Definições, Funções do Produto, Características do Usuário, Requisitos Funcionais e Requisitos Não-Funcionais. Modelo de Integração 8

9 Modelo Conceitual do SRS Modelo Conceitual da especificação de casos de uso 9

10 Modelo de Integração Campos de SRS proposto por Belgamo (TUCCA) 1. Introdução 3. Requisitos Específicos 1.1 Propósito 3.1 Interfaces Externas 1.2 Escopo 3.2 Requisitos Funcionais 1.3 Definições, Acrônimos e Abreviaturas 1.4 Referências 1.5 Visão Geral 2. Descrição Geral 2.1 Perspectiva do Produto Interfaces do Sistema Interfaces do Usuário Interfaces do Hardware Interfaces do Software Interfaces de Comunicação Restrições de Memória Operações Requisitos de Adaptação do Local 2.2 Funções do Produto 2.3 Características do Usuário 2.4 Restrições Gerais 2.5 Condições e Dependências 2.6 Distribuição dos Requisitos Entrada Processamento Resposta Situações Anormais Saída 3.3 Requisitos de Performance 3.4 Requisitos de Banco de Dados Lógico 3.5 Restrições de Design 3.6 Atributos de Sistema de Software Confiabilidade Disponibilidade Segurança Manutenabilidade Portabilidade 4. Informações de Suporte 4.1 Índice 4.2 Apêndices 10

11 Modelo Proposto de SRS 1. Introdução 3. Requisitos Específicos 1.1 Propósito 3.1 Interfaces Externas Escopo 3.2 Requisitos Funcionais 1.3 Definições, Acrônimos e Abreviaturas 1.4 Referências 1.5 Visão Geral 2. Descrição Geral 2.1 Perspectiva do Produto Interfaces do Sistema Interfaces do Usuário Interfaces do Hardware Interfaces do Software Entrada Processamento Resposta Situações Anormais Saída 3.3 Requisitos de Performance 3.4 Requisitos de Banco de Dados Lógico 3.5 Restrições de Design 3.6 Atributos de Sistema de Software Confiabilidade Disponibilidade Segurança Manutenabilidade Portabilidade 4. Informações de Suporte 4.1 Índice 4.2 Apêndices Interfaces de Comunicação Disponibilidade Restrições de Memória Operações Requisitos de Adaptação do Local 2.2 Funções do Produto 2.3 Características do Usuário 2.4 Restrições Gerais 2.5 Condições e Dependências 2.6 Distribuição dos Requisitos Modelo para Avaliação da Qualidade da Tradução entre Requisitos e Casos de Uso 11

12 Atributos de Qualidade do Modelo Completude Foco no documento: Todos os requisitos devem estar presentes no software. Existir todas as respostas para todas as entradas. Todas as páginas, tabelas e figuras numeradas. Foco na tradução: Todos os requisitos devem possuir um caso de uso correspondente. Todos os elementos presentes nos requisitos devem estar presentes também nos casos de uso correspondentes. Atributos de Qualidade (cont.) Não-ambigüidade Foco no documento: Todos os requisitos apresentarem única interpretação. Foco na tradução: Os casos de uso e os requisitos correspondentes devem ter a mesma interpretação. 12

13 Atributos de Qualidade (cont.) Consistência Foco no documento: Não existir conjuntos de requisitos que conflitem entre si. Foco na tradução: Não houver contradição entre os casos de uso e os requisitos correspondentes. Seleção das Métricas: GQM Métricas para requisitos que geram um ou mais casos de uso. Objetivo G1: Avaliar a qualidade em relação à completude da transcrição. Questão Q1: Todos os elementos presentes nos requisitos estão presentes nos casos de uso correspondentes? M1 = ((A1+A2+..+An) + (F1 +F2+..+Fn) + (RNF1+RNF2+..+RFNn)) (A + F + RNF) M1 = 1 tradução completa. M1 < 1 nem todos os elementos presentes no requisito estão mapeados nos casos de uso. 13

14 Seleção das Métricas: GQM cont. Objetivo G1: Avaliar a qualidade em relação à completude da transcrição. Questão Q2: Todos os atores identificados no requisito estão presentes no caso de uso correspondente? M3 = (A1 + A An) M3 = 1 todos os atores do requisito estão mapeados nos casos de uso correspondentes. M3 < 1 existem atores presentes nos requisitos que não estão nos casos de uso. A Seleção das Métricas: GQM cont. Objetivo G1: Avaliar a qualidade em relação à completude da transcrição. Questão Q5: A tradução dos requisitos para casos de uso está completa? 14

15 Seleção das Métricas: GQM cont. M8 = na M8 = 1 tradução completa. Todos os requisitos possuem pelos menos um caso de uso correspondente. M8 < 1 tradução incompleta. nr Seleção das Métricas: GQM cont. Objetivo G2: Avaliar a qualidade em relação à não ambigüidade da tradução. Questão Q6: Os requisitos e casos de uso correspondentes possuem a mesma interpretação? M10 = UCun UC M10 = 1 os requisitos e os U.C. correspondentes têm a mesma interpretação. M10 < 1 os requisitos e os U.C. correspondentes não possuem a mesma interpretação. 15

16 Seleção das Métricas: GQM cont. Objetivo G3: Avaliar a qualidade em relação à consistência da tradução. Questão Q7: Os requisitos e casos de uso correspondentes são consistentes entre si? M12 = UCc M11 = 1 o requisito e os U.C. correspondentes estão consistentes. M11 < 1 o requisito e os U.C. correspondentes estão contraditórios. UC Avaliação do Modelo Dois sistemas: Comunicador Instantâneo SIMULARE Avaliação da qualidade dos SRS Grupo de alunos de mestrado na área de engenharia de software. Avaliação da tradução 16

17 Avaliação do Modelo cont. Sistema Comunicador Instantâneo Análise do SRS: Completude: Q = na / nr Q = 21 / 24 Q = 0,875 Ambigüidade: X = 22 / 24 X = 0,9166 Consistência: X = 24 / 24 X = 1 Avaliação do Modelo cont. Análise da tradução: [R5] O sistema deve permitir aos usuários (professores, monitores, alunos e secretários) a conversação via texto, áudio, vídeo e videoconferência. 17

18 Avaliação do Modelo cont. Avaliação do Modelo cont. 18

19 Avaliação do Modelo cont. Elementos identificados no requisito: Funções F = 4 (conversação via texto, áudio, vídeo e videoconferência). Atores A = 4 (professores, monitores, alunos e secretários). Requisitos não funcionais não identificado. Elementos identificados no caso de uso 4.3: Funções F1 = 2 (conversação via texto e via áudio). Atores A1 = 4 (professores, monitores, alunos e secretários). Requisitos não funcionais não identificado. Elementos identificados no caso de uso 4.4: Funções F2 = 1 (conversação via videoconferência). Atores A2 = 4 (professores, monitores, alunos e secretários). Requisitos não funcionais não identificado. Avaliação do Modelo cont. Completude da tradução: M1 = ((A1+A2)+(F1 +F2)) / (A+F) M1 = ((4) + (2 + 1)) / (4 + 4) M1 = 0,875 Análise do mapeamento dos atores: M3 = (A1 + A2) / A M3 = (4 + 0) / 4 M3 = 1 Análise do mapeamento das funções: M5 = (F1 + F2) / F M5 = (2 + 1) / 4 M5 = 0,75 19

20 Avaliação do Modelo cont. Não ambigüidade da tradução: M10 = UCun / UC M10 = 1 / 2 M10 = 0,5 Consistência da tradução: M12 = UCc / UC M12 = 2 / 2 M12 = 1 Avaliação do Modelo cont. Completude do Mapeamento do Sistema Comunicador Instantâneo M8 = na / nr M8 = 14 / 24 M8 = 0,

21 Considerações sobre os mapeamentos Os dois sistemas adotaram o SRS proposto por IEEE. Encontrados problemas de ambigüidade nos SRS. Encontrados problemas no mapeamento nos dois sistemas nos atributos completude e não ambigüidade. Considerações Finais As métricas apresentadas neste trabalho foram uma adaptação das métricas encontradas na literatura. O modelo permite: Identificar o foco do problema. Descobrir os requisitos omissos no SRS por pessoas que não estejam envolvidas no processo de desenvolvimento do software. Aplicar as métricas em requisitos que geram um ou mais casos de uso. O modelo define o local para o registro dos requisitos: Omissos. Que receberam mapeamento completo. Que receberam mapeamento incompleto. Que não possuem casos de uso correspondente. 21

22 Contribuições Facilitar o processo de transcrição para casos de uso. Descobrir os requisitos omissos no SRS sem estar envolvido no processo do desenvolvimento do software. Geração de documentos na fase de especificação de um sistema (SRS e casos de uso) com qualidade e consistência. Independência de conhecimento de quem desenvolveu o SRS para descrever os casos de uso. Qualidade do produto final do software evitando os custos decorrentes de um produto implantado a partir de falhas de qualidade nos seus estágios iniciais. Trabalhos Futuros Estudo e a adaptação de novos atributos e métricas que possam ser aplicados na análise da tradução. A aplicação do modelo em projetos de maior complexidade. Criação de uma ferramenta de apoio para a aplicação do modelo. 22

23 PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO SUL PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO Um Modelo para Avaliação da Qualidade da Tradução de Requisitos para Casos de Uso MSc. Fabiana Zaffalon Ferreira Rocha Prof. Dr. Ricardo Melo Bastos Prof. Dr. Marcelo Hideki Yamaguti MSc. Elisa Cerri e Cerri Dezembro / 2007 Trabalho desenvolvido no convênio PUCRS/Dell Computadores do Brasil Ltda. com recursos da Lei 8.248/91 Métrica Completude Completude = nu / (ni x ns) Onde: nu é a função única ni é o estímulo de entrada da função ns é o estado da entrada da função 23

24 Métrica Completude Proposta de Alexander Completude = na / nr Métrica Não Ambigüidade Não ambigüidade = nui / nr Onde: nui é o número de requisitos com única interpretação nr é o número de requisitos no documento 24

25 Métrica Consistência Consistência = nc / nr Onde: nc é o total de requisitos que estão consistentes. nr é o total de requisitos do SRS 25