Engenharia de Software II



Documentos relacionados
Engenharia de Software II

Engenharia de Software II

Engenharia de Software II

Engenharia de Software II

Engenharia de Software II

Engenharia de Software II

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

Engenharia de Software II

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

Teste de Software Estrutural ou Caixa Branca. Disciplina de Engenharia de Software prof. Andrey Ricardo Pimentel

Engenharia de Software II

Engenharia de Software II

PROFESSOR: CRISTIANO MARIOTTI

Juciara Nepomuceno de Souza Rafael Garcia Miani. Teste de Software

EVOLUÇÃO DE SOFTWARE

natureza do projeto e da aplicação métodos e ferramentas a serem usados controles e produtos que precisam ser entregues

Engenharia de Software. Parte I. Introdução. Metodologias para o Desenvolvimento de Sistemas DAS

APLICATIVO PARA CÁLCULO DE MÉTRICA DE SOFTWARE EM CÓDIGO-FONTE PL/SQL

Engenharia de Requisitos

IES-300. Tecnologia em Análise e Desenvolvimento de Sistemas Prof. Me. Álvaro d Arce alvaro@darce.com.br

ENG1000 Introdução à Engenharia

Testes de Software. Testes de Software. Teste de Validação. Teste de Defeito. Modelo de Entrada e Saída. Modelo de Entrada e Saída

ARQUITETURA DE SOFTWARE

Projeto de Arquitetura

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr

Ciclo de Vida Clássico ou Convencional CICLOS DE VIDA DE DESENVOLVIMENTO DE SISTEMAS. Ciclo de Vida Clássico ou Convencional. Enfoque Incremental

MODELAGEM DE SISTEMAS DE INFORMAÇÃO

Testes de Software. Testes de Software. Teste de Validação. Teste de Defeito. Modelo de Entrada e Saída. Modelo de Entrada e Saída

UML - Unified Modeling Language

Projectos de Software

Engenharia de Software II

Prof. Marcelo Machado Cunha

MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS

UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO DEPARTAMENTO DE ESTATÍSTICA E INFORMÁTICA BACHARELADO EM SISTEMAS DE INFORMAÇÃO RAPID APPLICATION DEVELOPMENT

Objetivos. Processos de Software. Tópicos abordados. O processo de software. Modelos genéricos de modelos de processo de software.

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga

Técnicas de Teste de Software

Engenharia de Software

Agenda. Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria

AULA 1 INTRODUÇÃO - ENGENHARIA DE SOFTWARE. Prof. Msc. Hélio Esperidião

1) MANUAL DO INTEGRADOR Este documento, destinado aos instaladores do sistema, com informações de configuração.

Auditoria e Qualidade de Software ISO/IEC 9126 Engenharia de Software Qualidade de Produto

Acadêmicos: Luís Fernando Martins Nagata Gustavo Rezende Vinícius Rezende Santos

Modelos do Design de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

Sistemas de Informação I

Unidade VI. Validação e Verificação de Software Teste de Software. Conteúdo. Técnicas de Teste. Estratégias de Teste

Qualidade de Software. Profa. Cátia dos Reis Machado

Gerência de Projetos

Implantação de um Processo de Medições de Software

Organização e Arquitetura de Computadores I

Introdução ao Processo Unificado (PU)

Plano de projeto. Cronograma e Controle

Desempenho e Segurança em Sistemas de Informação. Profa.: Me. Christiane Zim Zapelini christianezapelini@nwk.edu.br

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

UNIVASF - Universidade Federal do Vale do São Francisco Manutenção de Software

Qualidade de Software. Prof.: Ivon Rodrigues Canedo. PUC Goiás

Engenharia de Requisitos

Paradigmas de Engenharia de Software

Planejamento de Projetos. Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( )

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi

FACULDADE DE ENGENHARIA DE COMPUTAÇÃO. PROJETO FINAL I e II PLANO DE TRABALHO <NOME DO TRABALHO> <Nome do Aluno> <Nome do Orientador>

Árvores. Algoritmos e Estruturas de Dados 2005/2006

Como melhorar a Qualidade de Software através s de testes e nua. Cláudio Antônio de Araújo 22/11/2008

Engenharia Reversa e Reengenharia

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

Engenharia de Software

Referências internas são os artefatos usados para ajudar na elaboração do PT tais como:

Conteúdo. Disciplina: INF Engenharia de Software. Monalessa Perini Barcellos

2.Gerência de Projetos: Métricas de Software

Professor: Curso: Disciplina:

RAID. Propõe o aumento da confiabilidade e desempenho do armazenamento em disco. RAID (Redundant Array of Independent Disks )

Engenharia de Software: conceitos e aplicações. Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com

Manutenção desoftware. SCE 186- Engenharia de Software Profs. José Carlos Maldonado e Elisa Yumi Nakagawa 2 o semestrede2002

Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios

Engenharia de Software

Políticas de Qualidade em TI

Orientação à Objetos. Aécio Costa


Algoritmos e Programação (Prática) Profa. Andreza Leite andreza.leite@univasf.edu.br

Qualidade de Software

MUDANÇAS NA ISO 9001: A VERSÃO 2015

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Teste de Software. Objetivos e Limites. Objetivos e Limites. Objetivos e Limites. Objetivos e Limites. Objetivos e Limites

Engenharia de Software

Concepção e Elaboração

PRIMAVERA RISK ANALYSIS

Capítulo 2. Processos de Software Pearson Prentice Hall. Todos os direitos reservados. slide 1

Fundamentos de Teste de Software

GESTÃO DAS INFORMAÇÕES DAS ORGANIZAÇÕES MÓDULO 11

Desenho de Software. Desenho de Software 1

Engenharia de Software: Introdução. Mestrado em Ciência da Computação 2008 Profa. Itana Gimenes

Manutenção e Ferramentas CASE. Marcos L. Chaim Segundo Bimestre 2003 Mestrado Profissional IC/Unicamp

MÉTRICAS DE SOFTWARE

Engenharia de Software II

Metodologia e Gerenciamento do Projeto na Fábrica de Software v.2

Transcrição:

Engenharia de Software II Aula 16 http://www.ic.uff.br/~bianca/engsoft2/ Aula 16-14/05/2006 1

1. O que é uma atividade guarda-chuva? Dê dois exemplos. São atividades aplicáveis durante todo o processo de software. Exemplos: medição, gestão de risco, testes, revisões formais. Aula 16-14/05/2006 2

2. Qual é a principal desvantagem de se aperfeiçoar um protótipo para torná-lo um produto de produção? A principal desvantagem é gerar um produto final de baixa qualidade porque: O protótipo é feito para demonstrar funcionalidade rapidamente, logo seu projeto raramente é bem feito. As escolhas feitas para o protótipo (linguagem, algoritmos, arquitetura) raramente são apropriadas para o produto final. Aula 16-14/05/2006 3

3. Dadas as características de cada projeto de software abaixo, indique qual o modelo de processo é o mais apropriado. a) Diferentes níveis de funcionalidade e pouca disponibilidade de mão-de-obra: incremental. b) Requisitos fixos, orçamento fixo e funcionalidade simples: cascata. c) Orçamento flexível, requisitos mal definidos e cronograma flexível: espiral. d) Requisitos fixos, funcionalidade modularizável, prazos curtos e grande disponibilidade de mão de obra: RAD. Aula 16-14/05/2006 4

4. Sobre o processo XP (Extreme Programming): a) Os testes de unidade devem ser criados antes ou depois do código? Por quê? Antes. Porque o então o desenvolvimento fica mais orientado para passar nos testes, ou seja, cumprir os requisitos. Além disso, facilita a aplicação dos testes assim que o código fica pronto. b) Cite uma vantagem da programação em pares. A principal vantagem é o controle de qualidade em tempo real. Enquanto um programador escreve o código, o outro verifica se o programa segue as normas de qualidade. Além disso, a programação em pares possibilita a resolução de problemas em tempo real. Aula 16-14/05/2006 5

5. Sobre estratégias de teste: a) O que é um pseudo-controlador (driver)? É um programa que recebe os dados do caso de teste, passa os dados ao componente a ser testado e imprime os resultados relevantes. b) O que é um pseudo-controlado (stub)? É um programa que substitui módulos que são chamados pelo componente a ser testado. Ele tem a mesma interface do módulo sendo substituído, mas com o mínimo de funcionalidade. c) Cite uma vantagem e uma desvantagem da integração descendente. Vantagem: demonstração de capacidade funcional logo no início. Desvantagem: necessidade de criação de pseudo-controlados. Aula 16-14/05/2006 6

6. Sobre o fluxograma ao lado: a) Transforme o fluxograma em um grafo de fluxo. A,B C D E F G H Aula 16-14/05/2006 7

b) Calcule a complexidade ciclomática. V(G) = E N + 2 = 9 7 + 2 = 4 C A,B R 2 D V(G) = 4 regiões E R 1 F H R 3 R 4 G V(G) = P + 1 = 3 + 1 = 4 Aula 16-14/05/2006 8

c) Dê um conjunto-base de caminhos independentes para esse grafo de fluxo. A,B A,B,C,E,H A,B,C,F,H E C F D G A,B,D,H H A,B,D,G,H Aula 16-14/05/2006 9

d) Prepare casos de teste para exercitar cada caminho independente, especificando o valor de x na entrada e na saída. A,B,C,E,H: entrada x=1, saída x=2 A,B,C,F,H: entrada x=3, saída x=4 A,B,D,H: entrada x=5, saída x=5 A,B,D,G,H: entrada x=7, saída x=9 Aula 16-14/05/2006 10

7. Sobre a análise de valor limite (BVA): a) Qual é o objetivo da BVA? O objetivo da BVA é testar o funcionamento do programas nos valores limites das classes de equivalência de entrada, onde normalmente ocorrem erros. b) Quando uma condição de entrada especifica um intervalo limitado pelos valores a e b, que casos de teste devem ser criados segundo a BVA? Casos de teste com valores a e b, e imediatamente acima e abaixo de a e de b (a-1, a+1, b-1 e b+1). Aula 16-14/05/2006 11

8. Que falhas são detectadas pelo teste de matriz ortogonal e não por testes de modo singular? Dê uma justificativa. Falhas de modo duplo, isto é, falhas que involvem uma combinação de dois parâmetros. O teste de modo singular testa cada parâmetro independentemente, enquanto o teste de matriz ortogonal garante que cada combinação de dois parâmetros é testada. Aula 16-14/05/2006 12

9. Na métrica ponto por função, qual é a diferença entre uma entrada externa e uma consulta externa? A entrada externa geralmente modifica algum arquivo lógico interno e fornece informação de controle. A consulta externa resulta na geração de uma saída imediata e não modifica nenhum arquivo. Aula 16-14/05/2006 13

10. Explique como as seguintes métricas CK são calculadas: a) Acoplamento entre as classes de objetos. É calculada através das colaborações listadas para cada classe. Soma-se o número de colaborações para cada classe. a) Falta de coesão em métodos. É o número de métodos que têm acesso a um ou mais dos mesmos atributos. Para cada atributo, verifica-se quantos métodos lêem ou modificam o atributo. Aula 16-14/05/2006 14

Ementa Processos de desenvolvimento de software (Caps. 2, 3 e 4 do Pressman) Estratégias e técnicas de teste de software (Caps. 13 e 14 do Pressman) Métricas para software (Cap. 15) Métricas para o modelo de análise Métricas para o modelo de projeto Métricas de código fonte Métricas para teste Gestão de projetos de software: conceitos, métricas, estimativas, cronogramação, gestão de risco, gestão de qualidade e gestão de modificações Reengenharia e engenharia reversa Aula 16-14/05/2006 15

Métricas para Projeto Orientada a Objeto Métricas orientadas a classe Métricas CK Métricas MOOD Métricas de Lorenz e Kidd Métricas orientadas a operação Aula 16-14/05/2006 16

Métricas MOOD Fator de herança de métodos (MIF) Mede o grau em que a arquitetura de classes de um sistema OO faz uso de heranças. MIF = Σ i M h (C i ) / Σ i M t (C i ) onde M h é o número de métodos herdados e M t é o número total de métodos (herdados + definidos). Fator de acoplamento (CF) Dá uma indicação das conexões entre os elementos do projeto OO. CF = Σ i Σ j é_cliente(c i,c i ) / (n 2 -n) onde n é o número de classes. Aula 16-14/05/2006 17

Métricas de Lorenz e Kidd Em um livro sobre métricas OO, Lorenz e Kidd dividem as métricas baseadas em classe em quatro categorias amplas: Tamanho: contagem de atributos e operações para uma classe individual e valores médios para o sistema. Herança: modo pelo qual as operações são reusadas ao longo da hierarquia de classes. Estrutura interna: coesão e operação. Estrutura externa: acoplamento. Aula 16-14/05/2006 18

Métricas Orientadas a Operação São métricas para os métodos (operações) que residem dentro de uma classe. Exemplos: Tamanho médio da operação: é o número de mensagens (chamadas de outros métodos). Complexidade da operação: pode ser calculada usando qualquer das métricas de complexidade propostas para software convencional (por exemplo, complexidade ciclomática). Número médio de parâmetros por operação. Aula 16-14/05/2006 19

Métricas de Código-Fonte Halstead foi o primeiro cientista a propôr leis quantitativas para o desenvolvimento de software em 1977. A utilidade dessas métricas é um assunto controverso na comunidade de engenharia de software. Elas são usadas principalmente para estimar o esforço de manutenção do código. Aula 16-14/05/2006 20

Métricas de Halstead Baseadas nas seguintes medidas: n 1 : número de operadores (aritméticos e de fluxo de controle) distintos que aparece em um programa. n 2 : número de operandos (variáveis e constantes) distintos que aparece em um programa. N 1 : número total de ocorrências de operador. N 2 : número total de ocorrências de operando. A partir dessas medidas, cinco métricas são derivadas: Tamanho: N = N 1 + N 2 Vocabulário: n = n 1 + n 2 Volume: V = N log 2 n (informação em bits necessária para especificar o programa). Dificuldade: D = (n 1 /2)(N 2 /n 2 ) Esforço: E = V*D Aula 16-14/05/2006 21

Métricas para Teste As métricas de complexidade podem ser utilizadas para estimar o esforço de teste. Complexidade ciclomática Coesão e acoplamento do projeto OO O esforço de teste também pode ser estimado usando a métrica de esforço de Halstead. A porcentagem total de teste a ser alocada a um módulo k pode ser estimada usando a seguinte relação: % do esforço de teste (k) = e(k)/σ i e(i) Aula 16-14/05/2006 22

Métricas para Teste OO As métricas OO que tem influência direta na testabilidade do sistema são: Falta de coesão em métodos Porcentagem pública e protegida % de atributos que são públicos ou protegidos Acesso público a dados Número de classes que podem acessar atributos de outra classe. Número de classes raiz Convergência (fan-in) Indica se uma classe herda de mais de uma classe raiz. Número de filhos Profundidade da árvore de herança Aula 16-14/05/2006 23

Métricas de Manutenção O índice de maturidade de software (SMI) fornece uma indicação da estabilidade de um produto de software, com base nas modificações. Sendo: M T = número de módulos na versão corrente F c = número de módulos na versão corrente que foram modificados F a = número de módulos na versão corrente que foram adicionados F d = número de módulos na versão anterior que foram descartados na versão corrente. SMI = [M T (F a + F c + F d )]/M T Aula 16-14/05/2006 24