1 / 37

Engenharia de Software

Engenharia de Software. Introdução a Eng. de Software Engenharia de Requisitos. Prof. Me. Humberto Moura. Objetivos. - Conhecer o Processo de engenharia de requisitos; - Aplicar Técnicas de elicitação de requisitos;. Projetos de Software Bem Sucedidos. Quando o cliente está satisfeito?.

cissy
Download Presentation

Engenharia de Software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Engenharia de Software Introdução a Eng. de Software Engenharia de Requisitos • Prof. Me. Humberto Moura

  2. Objetivos - Conhecer o Processo de engenharia de requisitos; - Aplicar Técnicas de elicitação de requisitos;

  3. Projetos de Software Bem Sucedidos • Quando o cliente está satisfeito? • Pós-Graduação em Engenharia de Requisitos de Software • 11

  4. Problema do Projetos de Software

  5. Erro em Requisitos • 41% • Erro no Projeto Lógico • 28% • Fontes de erros em um projeto da US Air Force • 17 • Pós-Graduação em Engenharia de Requisitos de Software

  6. Requisito • É uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar, para atingir os objetivos de negócio do cliente. • Pós-Graduação em Engenharia de Requisitos de Software • 24

  7. Principais Causas de Fracasso em Projetos de Software • - Falta de método e técnicas para produzir os requisitos • - Falta de entendimento do negócio do cliente • Pós-Graduação em Engenharia de Requisitos de Software • 13

  8. Custo Relativo para Reparar um Erro • Estudos realizados pela GTE, TRW e IBM, mediram e avaliaram os custos dos erros de requisitos ocorridos em várias fases do ciclo de vida de projetos de desenvolvimento de software. • Pós-Graduação em Engenharia de Requisitos de Software • 16

  9. Sistema de Informação • A transformação de dados em informação é um processo ou uma série de  atividades logicamente relacionadas, executadas para atingir um resultado definido. • 19 • Pós-Graduação em Engenharia de Requisitos de Software

  10. SISTEMA DE INFORMAÇÃO – S.I. • 18 • Pós-Graduação em Engenharia de Requisitos de Software

  11. SISTEMA DE INFORMAÇÃO – S.I. • 20 • Pós-Graduação em Engenharia de Requisitos de Software

  12. Processo • “Grupo de atividades realizadas numa sequência lógica com o objetivo de produzir um bem ou um serviço que tem valor para um grupo específico de clientes.” (Hammer e Champy, 1994) • 21 • Pós-Graduação em Engenharia de Requisitos de Software

  13. Sistema de Informação • Análise de Negócio • 23

  14. Cliente solicita: “Traga-me uma pedra” 2. Você, ao entregar a pedra, ouve: “Ok, mas, na verdade, o que eu realmente queria era uma pequena pedra de cor azul.” • Metáfora da Pedra

  15. Metáfora da Pedra • Sistemas de software são, por sua natureza, intangíveis, abstratos, complexos e mutáveis. • O cliente inicia a articulação de requisitos vagos para o seu sistema “pedra”. • O cliente, frequentemente, acredita que pode detalhar melhor o que precisa ao longo do desenvolvimento. • Não há como criar, testar, desenvolver e manter um sistema “pedra” a custo zero e prazo indefinido.

  16. Um cliente apresenta a seguinte necessidade: - Quero um programa que calcule a área de um retângulo. • Exemplo

  17. O usuário deve informar o valor (em metros) de cada um dos lados, com precisão de duas casas decimais. A fórmula a ser utilizada é: L1 * L2 O valor calculado deve ser informado também com precisão de duas casas decimais, com truncamento simples. O cálculo deve ser disparado após comando do usuário. • A informação é suficiente?

  18. Apresentar mensagem de erro quando, ao acionar o comando de cálculo, L1 e/ou L2 for(em) zero ou não for(em) especificado(s). Apresentar mensagem de erro se L1 = L2. Definir um limite máximo para as entradas L1 e L2. Incluir uma opção para limpar as entradas de dados. O programa deve operar em no sistema operacional Windows XP ou superior. Não há necessidade de impressão ou salvamento do resultado. O programa deve ser capaz de operar sem o uso do mouse. O resultado deve ser apresentado em até 1 segundo após o acionamento do comando de cálculo. Definir as mensagens. • E agora? • Melhorou ???

  19. Relacionando Conceitos • Mapeamento • do • Processo • Identificação • do • Problema • Definição • dos • Objetivos • Análise do • Problema • Sistema de informações / Processos / Requisitos • Definição • dos • Requisitos • Proposta • de • Solução • Análise • do • Negócio • Produção e • Gerência • de • Requisitos • Viabilidade • Funcionalidades • e • Recursos • Engenharia • de • Requisitos • 37 • Pós-Graduação em Engenharia de Requisitos de Software

  20. Identificação e Análise de Requisitos • Trabalha-se com o cliente • Entrevistas, simulações, documentos de referencia,... • Identificar as pessoas, os processos e as relações • Definir o limite do sistema • Registram-se os requisitos • Desenvolvedores e Cliente em consenso • Documento de Definição de Requisitos - DDR • Verificam-se os requisitos • Completos, corretos e consistentes • Validam-se os requisitos • Elaboração de Protótipos • Monitora e controla as mudanças nos requisitos • 43 • Pós-Graduação em Engenharia de Requisitos de Software

  21. Documento de Requisitos • Domínio do • PROBLEMA • Requisitos do • Negócio • Necessidades • Recursos, • Perfil, • Prazo e Custo • (Requisitos • de Usuário) • Características • Domínio da • SOLUÇÃO • Requisitos de Software • ou de Sistema • Não Funcionais • Funcionais • Complementares • Regras de Negócio

  22. Documento de Requisitos • Clientes • Projetistas • Definição dos Requisitos • Especificação dos Requisitos • Redefine os requisitos em termos técnicos; • Compreensível para o Projetista • Consenso entre Analista e Desenvolvedor • Envolve Modelagem • Lista do que o Cliente espera que o sistema faça; • Compreensível ao Cliente; • Consenso entre Cliente e Analista;

  23. Não importa o método, deve-se manter um conjunto de documentos que registrem os requisitos Esse conjunto será utilizado durante todo o desenvolvimento e manutenção do sistema • Documentação dos Requisitos

  24. Engenharia de Requisitos • "Criar e manter a documentação de requisitos do sistema."

  25. Produção de Requisitos • Elicitação • Identificação da fonte de informação. Obtenção dos dados e fatos. Reunião com o cliente para entendimento do negocio. • Análise de Requisitos • Identificação dos requisitos a partir do processo de negócio. Acordo com o cliente do que se vai automatizar. • Documentação • Definição dos requisitos. Elaboração do documento de definição dos requisitos e regras de negocio. Documentação • Validação • Avaliar, junto ao cliente, se os requisitos realmente definem o sistema que o cliente deseja; Protótipo.

  26. Rastreabilidade Relação entre as fontes dos requisitos, os requisitos propriamente ditos e outros artefato Gerência de Mudanças Controla as solicitações de mudança do cliente Gerência de Configuração Controla as versões dos artefatos Gerência de Qualidade dos Requisitos Define o padrão de produção e verificação da qualidade dos requisitos. Capacita os analistas de requisitos e elabora o plano de gerencia de requisitos. • Gerência de Requisitos

  27. Exercício - Estudo de Caso • Dividam-se em grupos de 5 alunos, onde 1 aluno é o cliente, e • para o sistema descrito a seguir escrever os requisitos funcionais, complementares, regras de negócio e não funcionais que forem identificados.

  28. FIM • Inicio • Cadastra Usuario e Senha • Seleciona • Opção de Compra • Solicita • Usuário e Senha • Valida Usuário e Senha • Sistema Envia • e-mail • Cadastra • Endereço de Entrega • Busca Produto • Modifica • Produto • Confirma Compra • Fecha a Venda • Visualiza • Produto • Adiciona • Produto • Estudo de Caso • Possui • Cadastro? • Processo de Compra na WEB • Achou ? • Finaliza? • Não • Sim • Não • Sim • Sim • Não

  29. Possíveis Respostas • Requisitos Funcionais • Sub-Processo Seleciona Produto • RF1 – O sistema deve buscar produto (rc01) • RF2 – O sistema deve adicionar produto (itens do carrinho) (rc02) • RF3 – O sistema deve visualizar produtos (itens do carrinho) (rc3) (rng1) (rng2) • RF4 – O sistema deve excluir produto (itens do carrinho) (rc01) • RF5 – O sistema deve alterar quantidade produto (itens do carrinho) (rc02) • RF6 – O sistema deve finalizar pedido (fechar carrinho) (rc04) (rgn3) (rgn4) (rgn5) (rgn6)

  30. Possíveis Respostas • Requisitos Funcionais • Sub-Processo Seleciona Realiza Compra • RF7 – O sistema deve identificar cliente (rc5) • RF8 – O sistema deve cadastrar cliente (rc6) • RF9 – O sistema deve cadastrar endereço de entrega (rc7) • RF10 – O sistema deve permitir ao cliente selecionar opção de pagamento (rc08) • RF11 – O sistema deve confirmar a compra (rc9) (rng7) • RF12 – O sistema deve enviar e-mail de status (rc10)

  31. Estudo de Caso • Requisitos Complementares • Sub-Processo Seleciona Produto • RC1 – o sistema deve permitir selecionar nome do produto (RF1) (RF4) • RC2 – o sistema deve permitir selecionar nome e quantidade (RF2) (RF5) • RC3 – o sistema deve exibir produto, quantidade, valor e total ao visualizar produto (carrinho) (RF3) • RC4 – o sistema deve permitir registrar nome, data e hora ao finalizar o pedido (RF6)

  32. Estudo de Caso • Requisitos Complementares • Sub-Processo Seleciona Realiza Compra • RC5 – o sistema deve identificar o cliente por usuário e senha ao finalizar o pedido (RF7) • RC6 – o sistema deve cadastrar usuário e senha (RF8) • RC7 – o sistema deve cadastrar endereço, bairro, cidade e cep (RF9) • RC8 – o sistema deve exibir as seguintes opções de pagamento: cartão de crédito e boleto bancário (RF10) • RC9 – o sistema deve registrar nome, data, hora, produto e quantidade ao confirmar o pedido (RF11) • RC10 – o sistema deve informar o status da compra (aguardando confirmação do cartão de credito ou do pagamento do boleto) ao finalizar a compra (RF12)

  33. Estudo de Caso • Regras de Negócio • RNG1 – quando o cliente visualizar os produtos (carrinho) o sistema deve permitir alteração de quantidade de itens(RF3) • RNG2 – quando o cliente visualizar os produtos (carrinho) o sistema deve permitir exclusão de itens(RF3) • RNG3 – quando o cliente finalizar o pedido o sistema deve identificar cliente (RF7) • RNG4 – quando o cliente finalizar o pedido e o cliente não for cadastrado o sistema deve permitir cadastrar cliente(RF8) • RNG5 – quando o cliente finalizar o pedido o sistema deve cadastrar endereço de entrega(RF9) • RNG6 – quando o cliente finalizar o pedido o sistema deve permitir selecionar tipo de pagamento(RF10) • RNG7 – quando o cliente confirmar a compra o sistema deve enviar e-mail informando status da compra(RF12)

  34. 1. Confiablidade  O sistema deve garantir que a atualização de dados será feita de forma atômica e imediata, sempre com registro histórico; O sistema deve realizar backups diariamente após a 00:00 hrs; 2. Eficiência O sistema deve responder a qualquer pesquisa, inclusão, alteração e exclusão em tempo inferior a 3 (três) segundos; O sistema deve garantir que as atualizações dinâmicas de informação única não devem exceder 1 (um) segundo; • Requisitos Não Funcionais

  35. 3. Portabilidade O sistema deve ser executado em em microcomputadores de arquitetura IBM PC, com processadores Intel P4 2.5Ghz com 512Mb de memória RAM e HD de 40Gb com sistema operacional Windows XP; O sistema deve ser portável para GNU/Linux, com ambiente Desktop GNOME, em máquina de mesma configuração; 4. Usabilidade O sistema deve focar em eficiência, fornecendo teclas de atalho para todas as ações mais importantes; O sistema deve seguir as Diretrizes de Interface Humana do projeto GNOME: http://developer.gnome.org/projects/gup/hig/; • Requisitos Não Funcionais

  36. Bibliografia PRESSMAN, Roger S. Engenharia de Software. Porto Alegre: McGraw-Hill, 2011. SOMMERVILLE, Ian. Engenharia de Software. São Paulo: Pearson Education - Br, 2011. SWEBOK - Guide to the Software Engineering Body of Knowledge (www.swebok.org) WIEGERS, Karl E. More About Software Requirements. 1a. Ed. –Redmond, Washington: Microsoft Press, 2006

More Related