Aula 1   introducao
Upcoming SlideShare
Loading in...5
×
 

Aula 1 introducao

on

  • 220 views

Disciplina de Engenharia de Requisitos. aula introdutória

Disciplina de Engenharia de Requisitos. aula introdutória

Statistics

Views

Total Views
220
Views on SlideShare
220
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Aula 1   introducao Aula 1 introducao Presentation Transcript

  • Pós Graduação em Desenvolvimento deSoftwareMódulo: Engenharia de RequisitosAula 1: Introdução à Engenharia de RequisitosProfessor: Licardino Siqueira Pires
  • Apresentação do Professor eAlunos
  • 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
  • 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.
  • O que é Requisitos
  • 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..
  • 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;.
  • 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;.
  • 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!!!.
  • Vídeo Engenharia de Requisitos.
  • 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.
  • 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)
  • 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
  • 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
  • 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!
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Atividades do Desenvolvimento• Análise• Projeto• Implementação• Teste
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Ciclo de vidaConcepçãoElaboraçãoConstruçãoTransição
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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?