Your SlideShare is downloading. ×
  • Like
Aula 1   introducao
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Aula 1 introducao

  • 66 views
Published

Disciplina de Engenharia de Requisitos. aula introdutória

Disciplina de Engenharia de Requisitos. aula introdutória

Published in Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
66
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
2
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Pós Graduação em Desenvolvimento deSoftwareMódulo: Engenharia de RequisitosAula 1: Introdução à Engenharia de RequisitosProfessor: Licardino Siqueira Pires
  • 2. Apresentação do Professor eAlunos
  • 3. Tópicos centrais da disciplina• Introdução à engenharia de requisitos• Processos de engenharia de requisitos• As etapas da engenharia de requisitos• Sistemas de informações estratégicas• Requisitos no RUP, MPS.Br, PmBook e SCRUM• ISO 12207 e ISO 15504• Criando produtos com requisitos ágeis• FDD• SCRUM• Métodos ágeis
  • 4. O que é Engenharia de Requisitos• Engenharia de requisitos é uma abordagem sistemática edisciplinada para a especificação e gerenciamento derequisitos com os seguintes objetivos:• Conhecer requisitos pertinentes, alcançar umconsenso entre os steakholders sobre os requisitos,documentando-os de acordo com a normas dadas egerenciando-as sistematicamente.• Compreender e documentar os desejos enecessidades dos steakholders, que especifica ogerenciamento de requisitos para minimizar o risco deentregar um sistema que não atende os desejos daspartes interessadas.
  • 5. O que é Requisitos
  • 6. O que é Requisitos• É o mapeamento das propriedades que um software deve terpara atender um problema em especial.• Ele deve descrever os entendimento dos objetivos dosusuários e traduzir esses objetivos em funcionalidades dosistema..
  • 7. Um caso real• O Sistema que queremos deve fazer isto, isto..., enesse caso também isto;• Sim, Sim estou anotando;• Conversei com os usuários e basicamente este é oSistema que teremos que desenvolver;• Sim chefe;• Ótimo, começaremos a especificar os requisitosimediatamente;.
  • 8. Um caso real• Quatro Meses Depois ...Srs. Usuários, após oemprego das mais modernas técnicas deespecificação, produzimos este documento quedescreve minuciosamente o Sistema;• Ótimo! Bom! Hum! ... é um documento com 300páginas e todos estes gráficos, tabelas .Enfim,vamos analisá-lo e voltamos a falar;.
  • 9. Um caso real• Depois de um mês e meio ...Sr. Analista, nosso pessoal analisou comcuidado o documento. Tivemos muitadificuldade e dúvidas em entendê-lo. Mas oque percebemos é que NÃO FOMOSCORRETAMENTE ENTENDIDOS!!!• Como não? Tudo que aí está, foi fruto de nossoentendimento pessoal. REALMENTE VOCÊSNÃO SABEM O QUE QUEREM!!!.
  • 10. Vídeo Engenharia de Requisitos.
  • 11. Quem são os Steakholders• Quem quer que se beneficie de modo direto ou indireto dosistema que está sendo desenvolvido.Coloque três interessados em uma sala e pergunte a eles que tipode sistema eles desejam. Você provavelmente obterá quatro oumais opiniões diferentes.
  • 12. Estatisticas• Quais as causas típicas de um projeto de software não tersucesso?• 72,8% por requisitos mal definidos ou faltantes• Qual o custo para correção de um problema emrequisitos?• Requisitos – R$ 150,00• Projeto – R$ 376,92• Construção – R$ 753,85• Testes – R$ 1130,77• Aceite – R$ 2261,54• Operação – R$ 4900,00Fonte: Média do custo de correção de um erro em requisitos por etapa (300 projetos T & M)
  • 13. Atividades da Engenharia de Requisitos• Atividades de Desenvolvimento• Levantamento e análise de requisitos, projeto eimplementação• Atividades de Gerência• Gerência de Projetos• Gerência de Configuração• Gerência de Reutilização• Atividades de Controle de Qualidade• Verificação, Validação e Garantia da Qualidade
  • 14. Panorama [Pressman]• O que é?• Compreensão do problema;• O que o cliente quer e comoos usuários finais vãointeragir.• Quem faz?• Engenheiro de software,gerentes, clientes e usuáriosfinais• Por que é importante?• Projetar um softwareelegante errado não servenada a ninguém• Quais são os passos?• Concepção, levantamento,elaboração, negociação,revisado e validado (pelocliente)• Qual é o artefato?• Entendimento escrito doproblema• Cenários de usuário, lista defunções, modelo de análiseou uma especificação• Fiz correto?• Revisão com o cliente eusuário final• Alerta:• Mesmo depois de todas as partes concordarem as coisas vão mudar e elas vão continuarmudando ao longo de todo o projeto
  • 15. Migração• Há vantagens em mudar o processo de desenvolvimento desistemas das empresas?Questão da Ferramenta• Comprar um martelo não transforma você em um arquiteto!
  • 16. UML• Unified Modeling Language.• Conhecer uma linguagem não implica na habilidade desaber usá-la para produzir artefatos úteis.• Escrever bons projetos é como escrever poesia. Não bastaconhecer a linguagem. É preciso dominar certas técnicas deescrita.
  • 17. Software Deselegante• O software deselegante é aquele software feito sem umaestrutura clara.• O software deselegante é aquele do qual não se conseguereusar partes e que não se consegue entender como funcionasem uma boa carga de documentação (e muitas vezes nemassim).• É também aquele no qual uma pequena modificação em umade suas características pode causar um não funcionamentogeneralizado.
  • 18. Software Elegante• O software elegante é o software cuja estrutura éintrinsecamente mais fácil de compreender, que éautodocumentado e pode ser compreendido em nível macroou em detalhes.• Ele é mais fácil de modificar: quando alguma de suascaracterísticas é mudada, ele continua funcionando.
  • 19. Soluções para prover elegância• Design Patterns - lições aprendidas ao longo dos anos emdiferentes projetos.•Um processo de desenvolvimento de software bem definido.
  • 20. Processo Unificado - UP• A motivação para o uso da abordagem de Craig Larman aoProcesso Unificado deve-se ao fato de que este é umprocesso bastante conciso e eficiente para análise e projetode sistemas orientados a objetos.• Neste método, cada artefato (documento ou diagrama) temuma razão muito clara para existir e as conexões entre osdiferentes artefatos são muito precisas.
  • 21. Atividades do Desenvolvimento• Análise• Projeto• Implementação• Teste
  • 22. Análise• A análise enfatiza a investigação do problema.• O objetivo da análise é levar o analista a investigar e adescobrir.• Para que esta etapa seja realizada em menos tempo e deforma mais precisa, deve-se ter um bom método de trabalho.
  • 23. Análise• Pode-se dizer que o resultado da análise é o enunciado doproblema, e que o projeto será a sua resolução.• Problemas mal enunciados podem até ser resolvidos, mas asolução não corresponderá às expectativas.
  • 24. Análise• A qualidade do processo de análise é importante porque umerro de concepção resolvido na fase de análise tem um custo;na fase de projeto tem um custo maior; na fase deimplementação maior ainda, e na fase de implantação dosistema tem um custo relativamente astronômico.
  • 25. Projeto• A fase de projeto enfatiza a proposta de uma solução queatenda os requisitos da análise.• Então, se a analise é uma investigação para tentar descobriro que o cliente quer, o projeto consiste em propor umasolução com base no conhecimento adquirido na análise.
  • 26. Implementação• A utilização de técnicas sistemáticas nas fases de análise eprojeto faz com que o processo de geração de código possaser automatizado.• Neste caso, cabe ao programador dominar as característicasespecíficas das linguagens, ferramentas, frameworks eestruturas de dados para adaptar o código gerado aosrequisitos indicados quando necessário.
  • 27. Testes• A fase de testes envolve os testes de unidade, feitos peloprogramador, para verificar se os componentes geradosatendem à especificação do projetista, e aos testes de casode uso, normalmente efetuados por um analista experiente,que visam verificar a adequação do sistema aos requisitosinicialmente levantados.
  • 28. As quatro Fases do Processo Unificado• A fase de concepção incorpora o estudo de viabilidade e uma parte da análise derequisitos.• A fase de elaboração incorpora a maior parte da análise de requisitos, a análise dedomínio e o projeto.• A fase de construção corresponde à programação e testes.• A fase de transição consiste na instalação e manutenção do sistema.
  • 29. Ciclo de vidaConcepçãoElaboraçãoConstruçãoTransição
  • 30. Análise de Requisitos• A análise de requisitos é fundamental para odesenvolvimento de sistemas, pois trata justamente dedescobrir o que o cliente quer com o sistema.• A análise de requisitos está associada ao processo dedescobrir quais são as operações que o sistema deve realizare quais são as restrições que existem sobre estas operações.
  • 31. Erro comum• Deve ficar claro ao analista que requisitos são coisas que ocliente ou usuário solicitam, e não coisas que ele, comoanalista, planejou.
  • 32. Análise de Domínio• A análise de domínio está relacionada à descoberta dasinformações que são gerenciadas no sistema, ou seja, àrepresentação e transformação da informação.
  • 33. Exemplo• No sistema de informações de uma videolocadora asinformações descobertas na análise de domíniopossivelmente seriam relativas aos clientes, às fitas, aosempréstimos, aos pagamentos, etc.
  • 34. Tipos de Informação• As informações têm dois aspectos que são analisados:estático (ou estrutural) e o funcional.• O modelo estático é representado no diagrama conhecidocomo modelo conceitual.• O modelo funcional pode ser representado através doscontratos de operações de sistema.
  • 35. Projeto• Pode-se dizer que o núcleo de um projeto orientado aobjetos consiste de um diagrama de classes.• Mas como é que se constrói um diagrama de classes?