engenharia-de-requisitos

4,125 views
3,812 views

Published on

Introdução à engenharia de requisitos.

Published in: Technology, Business
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,125
On SlideShare
0
From Embeds
0
Number of Embeds
36
Actions
Shares
0
Downloads
367
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide
  • CUMPRIMENTAR, AGRADECER CONVIDADOS VÔO PANORÂMICO X DETALHES CÉLERE O QUE O SOFTWARE FARÁ?
  • CONFUSÃO GARANTIDA SOFTWARE NÃO EXISTE NO VÁCUO OBJETIVO É O MESMO
  • ÊNFASE NA COMPUTAÇÃO DESCONHEÇO AS DEMAIS ÁREAS
  • SE NÃO CONHECEMOS AS NECESSIDADES DO CLIENTE, ENTÃO NÃO PODEMOS PROPOR UMA SOLUÇÃO
  • TODOS CLIENTES PROJETISTAS
  • NÃO É DIFÍCIL DEFINIR ATRIBUTOS, MAS OBTÊ-LOS OBJETIVO DA ER: MELHORAR A PONTARIA DO NOSSO ARQUEIRO
  • NÃO ESTÁ ADEQUADAMENTE ARMADO
  • VOLUME EUA X EUROPA BRASIL?
  • TAREFA FÁCIL CONTUNDÊNCIA DE ALGUNS LIÇÃO: REUNIR COM O CLIENTE, PERGUNTAR O QUE ELE DESEJA, REGISTRAR, ENTREGAR PARA A EQUIPE DE DESENVOLVIMENTO, QUE USA TECNOLOGIA NÃO DISPONÍVEL 2 ANOS ATRÁS E IMPLANTAR, PARA MUITOS, NÃO FUNCIONA.
  • DUAS PALESTRAS QUE SUCEDEM ESCLARECEM ESTE DIAGRAMA. EU NÃO ESQUECI E TALVEZ VCS NÃO ESQUEÇÃM: NICOLAU MAQUIAVEL, EM “O PRÍNCIPE” ESCREVEU ACERCA DAS DOENÇAS TÍSICAS: NO INÍCIO É DIFÍCIL DIAGNOSTICAR, MAS FÁCIL DE CURAR, COM O TEMPO, FÁCIL DE DIAGNOSTICAR E DIFÍCIL DE CURAR.
  • CONTA A HISTÓRIA QUE O MAUSOLÉU MAIS BONITO DO PLANETA É FRUTO DO AMOR DE UM GRANDE GUERREIRO PELA SUA MULHER. FÁBULA É INVENÇÃO MINHA: ESTE GUERREIRO TEVE QUE CONTAR COM ALGUÉM QUE CONSTRUI O MAUSOLÉU, OU SEJA, SUAS IDÉIAS TIVERAM QUE SAIR DA MENTE DELE E, DE FORMA FORMAL OU NÃO, SER TRANSFERIDA PARA A DE OUTRAS PESSOAS. ENTRE ELES, UM MODELO. NESTA FÁBULA, ELE IMAGINOU ASSIM O MAUSOLÉU, QUE FOI ASSIM INTERPRETADO PELA CONSTRUTORA DA ÉPOCA E FOI ASSIM REALIZADO. ESTA É UMA FÁBULA QUE SERVE COMO METÁFORA DE SUCESSO PARA ER.
  • OBSERVEM ESTA CHARGE. NÃO HÁ O QUE EXPLICAR. FALA DE UMA DAS DIFICULDADES IDENTIFICADAS ANTERIORMENTE: COMUNICAÇÃO.
  • SEM FÁBULAS E METÁFORAS, O QUE É COMUM? Duas perguntas terríveis que eu já ouvi! Elas me ferem profundamente! É a perplexidade total, de ambas as partes. Já ouvi alguém me perguntar “O que é isso?”, depois de três meses de desenvolvimento. COMO MUDAR O CENÁRIO?
  • EXECUTADAS DE FORMA ITERATIVA, INTERCALADA COM OUTRAS ATIVIDADES E PODE SE ESTENDER POR PRATICAMENTE TODO O CICLO DE DESENVOLVIMENTO DO SOFTWRE.
  • Se não elicio não há o que modelar. Se não modelo, não tenho o que validar. Se não valido, o usuário não estará satisfeito. Se não gerencio, as mudanças, que necessariamente ocorrem, instauram o caos. Gerenciar requisitos é crucial. Neste aspecto, rastreabilidade é a palavra forte. OU VOCÊ CONTROLA AS MUDANÇAS OU ELAS CONTROLAM VOCÊ.
  • REQUISITOS NÃO SÃO OBTIDOS COM EXTRATIVISMO. ELES NÃO ESTÃO À DISPOSIÇÃO. QUANDO OBTIDOS DOS USUÁRIOS, IN NATURA, QUASE SEMPRE PRECISAM SER PROCESSADOS.
  • REQUISITOS NÃO SÃO OBTIDOS COM EXTRATIVISMO. ELES NÃO ESTÃO À DISPOSIÇÃO. QUANDO OBTIDOS DOS USUÁRIOS, IN NATURA, QUASE SEMPRE PRECISAM SER PROCESSADOS.
  • NÃO VOU FORNECER DETALHES, JULIANO FARÁ ISSO. AQUI É IMPORTANTE RESSALTAR O QUE ELE IRÁ FALAR LÁ: NÃO EXISTE “UMA TÉCNICA”, “UM MÉTODO”, “UM ...”, QUE RESOLVA OS PROBLEMAS. CADA CASO EXIGE SER CONSIDERADO ISOLADAMENTE.
  • FALA-SE MUITO EM VÁRIAS ABORDAGENS, CONTUDO, LINGUAGEM NATURAL É PREDOMINANTEMENTE O PRINCIPAL MECANISMO DE REGISTRO. ANÁLISE ORIENTADA A OBJETOS. PARTICULARMENTE, QUANDO ALGUÉM DIZ QUE ESTÁ FAZENDO USO DE AOO PARA REGISTRO DE REQUISITOS, EM TODOS OS CASOS QUE CONHEÇO, EMPREGA UMA OUTRA FORMA PARA COMUNICAÇÃO COM O USUÁRIO E GUARDA OS ARTEFATOS OO PARA USO INTERNO. ENTENDO QUE AOO É ÚTIL À ER ENQUANTO FACILITA A ANÁLISE DO PROBLEMA. PARA REGISTRO PROPRIAMENTE DITO DOS REQUISITOS, NÃO CONSIDERO ESTA FERRAMENTA TÃO ATRAENTE QUANTO O EMPREGO DE CASOS DE USO.
  • PROPOSTAS OTIMISTAS, PORQUE FALAM EM BENEFÍCIOS QUE NÃO SÃO USUFRUÍDOS PELA INDÚSTRIA. MOTIVO PARA O DESCOMPASSO SÃO VÁRIOS: NOSSA MESA-REDONDA DEVE TRATAR DISSO.
  • Quem gasta de 15% a 30% de todos os custos de desenvolvimento pensando em ER? Quem usa o paradigma de objetos para registrá-los? Quem usa português para registrar os requisitos? Em oposição a outros como DFD, MER, UC, ... Quem faz uso de uma mistura de itens?
  • engenharia-de-requisitos

    1. 1. O início é a parte mais importante do trabalho
    2. 2. Sistema e software Engenheiro de Software Sistema Software (parte de um sistema)
    3. 3. Características operacionais do software, interface com outros elementos e restrições Visão externa do software Define o papel do software Refina o papel do software Criar modelos de dados, funções e comportamento Visão geral do sistema Quando? Engenharia de sistema Projeto de software Análise de Requisitos de software
    4. 4. Confusão garantida Engenharia de Software Engenharia de Requisitos Engenharia de Requisitos
    5. 5. <ul><li>Produz a especificação do sistema
    6. 6. Elemento software é tratado pela engenharia de software
    7. 7. Engenharia de Software inicia-se com a engenharia de requisitos </li></ul>Engenharia de Sistemas
    8. 8. Engenharia de Requisitos <ul><li>Entender o que o cliente deseja
    9. 9. Analisar necessidades
    10. 10. Avaliar exequibilidade
    11. 11. Negociar uma solução razoável
    12. 12. Especificar uma solução
    13. 13. Validar uma especificação
    14. 14. Gerenciar requisitos </li></ul>
    15. 15. O que é um requisito? <ul><li>Condição necessária para que se resolva um problema ou se atinja um objetivo
    16. 16. Condição que deve ser atendida ou apresentada por um sistema ou componente de sistema para satisfazer um contrato, um padrão, especificação ou outro documento formalmente imposto </li></ul>IEEE Std. 612.12-1990
    17. 17. Quando é feita?
    18. 18. Quando Outros nomes: Análise de requisitos, Requisitos, Análise, Análise de sistemas ,...
    19. 19. Fundamentos <ul><li>Ciências Sociais </li><ul><li>Política, psicologia social
    20. 20. Comportamento organizacional
    21. 21. Antropologia </li></ul><li>Ciências Cognitivas </li><ul><li>Representação de conhecimento
    22. 22. Lingüística </li></ul><li>Filosofia </li><ul><li>Epistemologia, ontologia,
    23. 23. Fenomenologia, Semiótica </li></ul></ul><ul><li>Teoria de Sistemas </li><ul><li>O que é um sistema?
    24. 24. Controle e evolução de sistemas </li></ul><li>Engenharia de Sistemas </li><ul><li>Ciclos de vida </li></ul><li>Matemática e Lógica </li><ul><li>Modelos relacionais
    25. 25. Modelos algébricos
    26. 26. Lógica temporal
    27. 27. Lógica modal </li></ul></ul>
    28. 28. Contexto e objetivo comportamento externo Domínio do Problema Domínio da Solução
    29. 29. Resultado <ul><li>O que construir?
    30. 30. O que esperar?
    31. 31. Como validar? </li></ul>Se não for bem escrito:
    32. 32. Quem se interessa pela ERS? <ul><li>Clientes Documenta o que deve ser entregue
    33. 33. Gerentes Planejamento de projeto
    34. 34. Projetistas de Software Define o que estes devem projetar
    35. 35. Controle de Qualidade de Software Base da validação, planejamento de teste e verificação </li></ul>Interessados = stakeholders
    36. 36. Conteúdo de uma ERS
    37. 37. ERS de “boa” qualidade <ul><li>Completa
    38. 38. Independente de implementação
    39. 39. Consistente
    40. 40. Não ambígua
    41. 41. Precisa
    42. 42. Verificável
    43. 43. Modificável
    44. 44. Legível
    45. 45. Organizada </li></ul>
    46. 46. Dificuldades para uma “boa” ERS <ul><li>Comunicação
    47. 47. Especificação de Requisitos </li><ul><li>Ambígua
    48. 48. Incompleta </li></ul><li>Volatilidade de requisitos
    49. 49. Registro de requisitos </li><ul><li>Notação </li></ul><li>Detalhes desconhecidos
    50. 50. Clientes numerosos
    51. 51. Clientes conflitantes
    52. 52. Clientes dispersos, ... </li></ul>
    53. 53. Evidências de dificuldades <ul><li>Standish Group, 1995 350 empresas americanas 8000 projetos
    54. 54. Fonte de falhas </li><ul><li>Pouco envolvimento do usuário (13%)
    55. 55. Requisitos incompletos (12%)
    56. 56. Mudança de requisitos (11%)
    57. 57. Expectativas irreais (6%)
    58. 58. Objetivos obscuros (5%) </li></ul></ul>cerca de 50% das causas de problemas <ul><li>European Software Institute, 1996 3800 organizações européias, 17 países
    59. 59. Principais problemas em software são </li><ul><li>Especificação de requisitos (> 50%)
    60. 60. Gerência de requisitos (50%) </li></ul></ul>
    61. 61. Motivação Requisitos Versão 89.2-A2
    62. 62. Motivação extra
    63. 63. “Nada é mais difícil e incerto do que conduzir a introdução de uma nova ordem de coisas.” Machiavelli Motivação
    64. 64. Fábula (sucesso)
    65. 65. Mausoléu X Qual o problema?
    66. 66. Charge (fracasso) Sobre as orelhas. Ok! King´s Kong Av. Anhangüera, 18...
    67. 67. Após muito esforço e atrasos, ... IRONIA INSATISFAÇÃO
    68. 68. Definição Requisitos
    69. 69. Classificação dos requisitos
    70. 70. Processo da ER: entradas/saídas
    71. 71. Processo Validação Modelagem Eliciação
    72. 72. Atividades da ER <ul><li>Eliciação </li><ul><li>Entrevista, análise de docs, ... </li></ul><li>Modelagem </li><ul><li>registrar requisitos </li></ul></ul><ul><li>Validação </li></ul><ul><li>Gerência </li><ul><li>rastreabilidade </li></ul></ul>
    73. 73. Por que eliciar? Você se sente melhor?
    74. 74. Descontração
    75. 75. Técnicas de eliciação <ul><li>Entrevistas e questionários
    76. 76. Workshops, Brainstorming
    77. 77. Storyboard
    78. 78. Casos de Uso
    79. 79. Representação (role playing)
    80. 80. Construção de protótipos
    81. 81. Análise de textos </li></ul>
    82. 82. Modelagem <ul><li>Linguagem natural (maioria dos casos) </li><ul><li>Seja sentença ou através de casos de uso </li></ul></ul><ul><li>Quais métodos podem ser empregados? </li><ul><li>Pseudocódigo
    83. 83. Máquina de estados finitos
    84. 84. Análise Orientada a Objetos
    85. 85. Análise Estruturada
    86. 86. Modelos entidade-relacionamento, ... </li></ul></ul>Ator Caso de uso C Caso de uso A Caso de uso B <<include>> Requerimento Boleto Bancário Comprovante Processo Parecer Autorização Sanciona Ajuda de Requerimento 0..1 1..n 0..1 1..n gera Avaliação de necessita Formulário de requerimento oficializado por
    87. 87. Há custos?
    88. 88. Teoria x Prática Supostos benefícios
    89. 89. O que os “bons” fazem? <ul><li>Usam métodos avançados (OO)
    90. 90. ER executada em várias rodadas
    91. 91. Revisões constantes com usuários
    92. 92. Protótipos + Modelos
    93. 93. Alocação de 15% a 30% do esforço total para ER </li></ul>
    94. 94. Onde procurar por informações? <ul><li>Livros http://easyweb.easynet.co.uk/~iany/reviews/reviews.htm
    95. 95. Gerência de requisitos http://www.jiludwig.com/
    96. 96. Ferramentas (>50) http://www. volere .co. uk/tools . htm </li></ul>
    97. 97. Considerações finais <ul><li>ER é imprescindível e, ao mesmo tempo, difícil!
    98. 98. Não menospreze os custos para execução adequada da engenharia de requisitos (cerca de 15% a 30% do custo total) </li></ul>

    ×