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

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Aula 1 introducao

77

Published on

Disciplina de Engenharia de Requisitos. aula introdutória

Disciplina de Engenharia de Requisitos. aula introdutória

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
77
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
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?

×