Resumo Engenharia de Software prova 2

Prévia do material em texto

Requisitos: Indica o que o sistema fará e com que restrições, é uma necessidade única que 
detalhe o que um produto ou serviço em particular deve fazer. 
 - Levantamento de Requisitos: Etapa de comunicação com cliente e obtenção das 
funcionalidades do sistema terá. 
 - Análise de Requisitos: Envolve verificar se a especificação dos requisitos dos 
requisitos é correta, completa, consistente, unívoca e realista. 
Documentos de Requisitos: Declaração oficial daquilo que se requer dos desenvolvedores do 
sistema, deve incluir definição dos requisitos de usuário e especificação de requisitos do 
sistema. 
Requisitos de usuário: São aqueles feitos no mais alto nível de abstração, feito para usuário 
leigo em computação par entendimento geral do sistema, o mesmo é feito para o cliente em 
linguagem natural. 
Requisitos de sistema: São versões mais expandidas (detalhadas) dos requisitos de usuário 
destinado a desenvolvedores/Engenheiros de Software, trata-se de um documento 
estruturado com descrições detalhadas sobre funções, serviços e restrições operacionais do 
sistema, além de definir o que deve ser implementado de uma forma que lhe permite ser 
parte do sistema. 
Especificação de Software: é o processo de descrever um sistema considerando as suas 
propriedades desejadas. 
Requisitos Funcionais: São requisitos que representam funcionalidades exigidas pelo cliente, 
mas não com restrições de como fazê-lo, condiz com o comportamento do sistema, por 
exemplo: O Sistema deve cadastrar usuário. 
Requisitos Não-Funcionais: São aqueles requisitos onde há declarações das restrições sobre 
serviços ou funções oferecidos pelo sistema incluindo restrições temporais, restrições no 
processo de desenvolvimento, padrões a seguir. 
 - Requisitos de Produto: Especificação de como o sistema tem de se comportar de 
determinada forma, como o mesmo deve ser feito/implementado exemplo: velocidade de 
execução ou confiabilidade, o sistema deverá ser implementado em Java. 
 - Requisitos Organizacionais: São consequências de políticas e procedimentos 
organizacionais, tais como, seguir as regras de um banco, a regra de uma locadora, enfim 
regras de negócio específicos de cada particularidade, podem ser também padrões, modelos 
que o cliente exija que sejam aplicados, exemplo: o sistema deve utilizar o padrão x para 
desenvolver o software 
 - Requisitos Externos: São aqueles que tem origem em fatores externos ao sistema e 
ao seu processo de desenvolvimento, como exemplo política de privacidade, requisitos legais 
ou de interoperabilidade, são aqueles também que devem obedecer legislações como de 
direitos autorais. 
Requisitos de Domínio: Tem origem no domínio da aplicação e refletem características desse 
domínio, como por exemplo um sistema de solução de sistemas lineares tem um método 
específico para resolver sistemas como gauss-seidel que é um requisito do domínio. 
 
Métricas de Requisitos: São medidas que se pode obter baseando-se em: 
 -Velocidade: Transações processadas por segundo, tempo de resposta ao 
usuário/evento, tempo de atualização da tela. 
 -Tamanho: Tamanho máximo em MB 
 -Facilidade de Uso: Tempo de treino, número de telas de ajuda 
 -Confiabilidade: Tempo médio entre falhas, taxa de ocorrência entre falhas, 
 -Robustez: Tempo de reinicio após falha, Percentagem de eventos que causaram a 
falha, probabilidades de dados corrompidos pós falhas 
 -Portabilidade: Percentagem de instruções dependendo do sistema alvo, número de 
sistemas alvo 
Teste de software: Processo de exercitar um programa com o objetivo específico de encontrar 
erros antes da entrega final ao usuário, os mesmo devem revelar presença de erros e não 
ausência, além de ser a única técnica de validação de requisitos não funcionais. 
Estratégias de Teste (Passos): 
 - Conduzir revisões do software regularmente 
 - Conduzir testes primeiro em nível de componente e prosseguir em direção à 
integração completa. 
 - Envolver tanto o desenvolvedor quanto os especialistas. 
Importância de Teste de Software: Mostrar erros, conformidades com requisitos, 
desempenho e indicação de qualidade. 
Teste de Unidade: Tem por objetivo testar a menor unidade do projeto (um componente de 
software que não pode ser subdividido), procurando identificar erros de lógica e de 
implementação em cada módulo separadamente. No paradigma estruturado, a menor 
unidade refere-se a um procedimento ou função. No paradigma orientado a objetos pode-se 
considerar uma classe ou um método; 
 
Teste de Integração: Visa descobrir erros associados a interfaces entre outros módulos 
quando esses são integrados para formar a estrutura do produto de software, focando assim 
na arquitetura de software. 
Teste de Validação: Tem por objetivo identificar erros de funções (requisitos funcionais) e 
características de desempenho, entre outros, (requisitos não-funcionais) que não estejam de 
acordo com as especificações. 
 
Teste de Sistema: Testa o software e os outros elementos do sistema do qual o software faz 
parte. 
 
Falta: é o problema, é detectada por teste 
Falha: é onde ocorre o erro, é detectada por depuração 
Depuração: Processo de diagnóstico e correção de erros, a depuração pode ser: Força bruta, 
rastreamento, eliminação de causa. 
Técnicas de Teste (Testabilidade): Operabilidade, Observabilidade, Controlabilidade, 
Decomponiblidade, Simplicidade, Estabilidade, Compreensibilidade. 
Característica de um bom teste: 
–Tem alta probabilidade de encontrar um erro 
–Não é redundante 
–Deve ser “de boa qualidade” 
–Não deve ser muito simples nem muito complexo 
Estrutura de um plano de teste: 
 
–O processo de teste 
–Rastreabilidade de requisitos 
–Itens que devem ser testados 
–Cronograma dos testes 
–Procedimentos de registro de testes 
–Requisitos de hardware e software 
–Restrições 
Técnicas de Teste: 
 - Exaustivo: Aquele que pode demonstrar que um programa é livre de defeitos, mas é 
um teste impossível. 
 -Seletivo: Aquele onde se escolhe um caminho por onde se vai testando todo o 
software. 
 
 
Gestão de Configuração de Software: Busca alocar recursos específicos para apoio de 
desenvolvimento de software e além disso auxilia no controle de diferentes versões do 
sistema. Contudo, a GSC é um importante elemento da garantia da qualidade de software. 
Problema de Atualização Simultânea: Solução: Biblioteca Central de Recursos Compartilhados 
Produto de Software: Programas de computador, procedimentos, documentação relacionada 
e informações designadas para serem entregues ao cliente/usuário final. 
Processo de GSC: Identificação, Documentação, Controle e Auditoria 
Tarefas de GSC: Identificação (Como a organização vai identificar as mudanças de forma 
eficiente), Controle de Mudança (Quem tem responsabilidade e quem vai aprovar as 
mudanças e quem prioriza as mudanças), Controle de Versão, Auditoria de configuração(pode 
ser funcional(preocupa-se com aspectos internos dos arquivos) ou física(determina 
características não consideradas durante a revisão), Relato de situação (Mecanismo para avisar 
sobre mudanças), Controle de interfaces (Que efeito que alterações externas vão causar ao 
sistema), Controle de Subcontratados e fornecedores(Garante que módulos implementados 
por terceiros estão corretamente adequados ao sistema). 
Conceitos Fundamentais: 
 -Linhas-Base: Ajuda a controlar as mudanças sem impedir seriamente as mudanças 
justificáveis, 
 -Repositórios: Local onde fica armazenado os itens de configuração geralmente são 
locais com controle de acesso (bancos de dados). 
 -Check-in/Check-out: Quando se deseja fazer alteração em algum item do repositório 
Projeto Estruturado – DFD: 
 Fluxo de dadosválidos: ligação direta independente da direção entre entidade externa e 
processo, processo ligado a outro processo e processo acessando depósito de dados. A figura a 
seguir apresenta alguns fluxos válidos. 
 
 
 
 Fluxos de dados inválidos: ligação direta entre entidades externas e ligação direta entre 
depósito de dados. A figura a seguir ilustra fluxo de dados inválidos. 
 
 
 
 
DFD contexto - são apenas os teminators e o sistema. 
DFD nível 0 - são os terminators, nomes dos processos superficialmente, só que aparece o 
nome dos fluxos (dados de entrada e saída). 
DFD nível 1 - é o de detalhe, aparecem os depósitos e há um detalhamento dos processos. 
 
MODELAR PROCESSOS COM ENTRADA E SAIDA 
Diretrizes para Elaborar um DFD 
 
1.Inicie identificando nomes de fluxos de entrada e saída 
2.Nomeie todos os fluxos de dados 
3.Evite nomes vagos como “Dados“ e ”Informações” 
4.Dê nomes antes aos fluxos de dados, depois aos processos 
5.Tente nomes de processos comum verbo de ação forte e um objeto direto singular-mais 
 de um verbo ou objeto pode indicar necessidade de particionar 
6.Cuidado com palavras vagas como Processar, manipular... 
7.O sistema descrito deve ser suposto em operação normal 
8.Retrate fluxo de dado senão de controle - na dúvida 
 Pergunte -se: que informações fluem pelo tubo? Se nenhuma, remova-o. 
9.Todo processo deve ter fluxo de entrada e de saída 
10.Evite DFD complexos demais 
11.Certificar-se que o DFD seja internamente consistente além de manter consistência com 
outros DFD,