1) objetivos engenharia de requisitos · 2014. 8. 22. · 1 engenharia de requisitos silvia...
Post on 05-Feb-2021
0 Views
Preview:
TRANSCRIPT
-
1
Engenharia de Requisitos
Silvia Regina Vergilio - UFPR
1) Objetivos
� O escopo do projeto é refinado em detalhe eserá produzida uma especialização de requisitos.
� ObjetivosFornecer traduzida Projeto, dadosinformação � procedimentos,
representações para arquitetura
1) Objetivos – Aspecto Fundamental
� Comunicação com o Uusário
“Eu sei que você acredita ter entendido o que você pensa que eu disse, mas não estou certo se você
está ciente de que o que você ouviu não é o que euqueria dizer.”
Cliente anônimo.
1) Objetivos - Documentos Gerados
� Especificação de Requisitos de Software
� Manual Preliminar do Usuário
� Plano de Projeto do Software (revisto).
2) Requisitos
� Requisito: condição necessária para a obtenção de certo objetivo ou para o preenchimento de certo fim
� Requisito de software: requisitos que o produto a ser desenvolvido deve possuir
2) Requisitos
� Requisitos funcionais: funcionalidade, o que o software deve fazer
� Requisitos não funcionais: confiabilidade (disponibilidade, integridade, segurança),acurácia, desempenho, interface HM, portabilidade, etc.
� Requisitos de desenvolvimento e manutenção, procedimentos de controle e qualidade
-
2
3) Engenharia de Requisitos
Passos:
� Entendimento do domínio de aplicação
� Extração de requisitos: classificação e organização
� Análise/Especificação dos requisitos –modelos
� Validação – necessidades do usuário
3.1) Extração de Requisitos
Processo de transformação das idéias que estão na mente do usuário (entradas) em um documento formal (saída).
3.1) Extração de Requisitos –Dificuldades
� Para conseguir informação pertinente.
� Para lidar com a complexidade. (Tornar o problema manipulável; detectar omissões, inconsistências )
� Para acomodar mudanças. (Coordenar, avaliar impacto; corrigir defeitos sem gerar erros)
3.1) Extração de Requisitos –Principais Causas
� 1. Deficiências na comunicação
� 2. Técnicas e ferramentas inadequadas
� 3. Desconsideração de alternativas.
É necessário aplicar:
-princípios fundamentais
-métodos/técnicas sistemáticos
3.1) Extração de Requisitos –O Analista
� Absorver fatos a partir de fontes conflitantes ou confusas.
� Entender os ambientes do usuário/cliente.
� Comunicamos bem na forma verbal e escrita.
� “ Enxergar a floresta apesar das árvores”
3.1) Extração de Requisitos –Tarefas
� 1. Reconhecimento (identificação doproblema )
� 2. Avaliação do problema e síntese desoluções gerais + critérios de validação.
� 3. Representação dos requisitos => software
� 4. Revisão da especificação reexame do Plano de Projeto de Software.
-
3
3.1) Extração de Requisitos –Quem participa
� desenvolvedor
� pessoal de apoio e documentação
� usuários ou potenciais usuários
� outras fontes de informações: pessoas e documentos
3.1) Extração de Requisitos –Procedimentos Genéricos
� Perguntar – identificar o usuário
� Observar e inferir – comportamento do usuário, inferir suas necessidades
� Negociar a partir de um conjunto padrão de requisitos
� Estudar e identificar problemas
� Supor – se o produto é novo comparar com existentes
3.1) Técnicas de Extração de Requisitos - Entrevistas
� Identificar candidatos
� Preparação para entrevista
� agendar
� preparar questões
� Condução da entrevista
3.1) Técnicas de Extração de Requisitos - Entrevistas
� Condução da entrevista
� apresentação e objetivos
� esperar respostas incompletas
� repetir frases do entrevistado com suas próprias palavras
� perguntas do tipo sim/não – dúvidas
� não se perder em detalhes
� o entrevistado precisa ter o contexto
3.1) Técnicas de Extração de Requisitos - Entrevistas
� Finalização
tempo, resposta à todas as perguntas
consolidar informações (5min), agradecimentos
� Geração de um documento escrito, planejar próximos passos
3.1) Técnicas de Extração de Requisitos - Braimstorming
� Técnica para geração de idéias
� Reuniões entre desenvolvedores e usuários
� Um líder é necessário
� Geração e consolidação das idéias
� Ausência de crítica e julgamento
� Elimina dificuldades de comunicação
-
4
3.1) Técnicas de Extração de Requisitos - PIECES
� Geralmente é aplicada na análise de produtos já existentes, mas pode ser adaptada
� Fornece um conjunto de categorias de questões e de problemas para odesenvolvedor extrair os requisitos
3.1) Técnicas de Extração de Requisitos - PIECES
Seis categorias:
P - desempenho
I - informação
E - economia
C - controle
E - eficiência
S - serviços
3.1) Técnicas de Extração de Requisitos - JAD
JAD – Joint Application Design
� Princípios básicos:
� dinâmica de grupo
� uso de técnicas visuais
� manutenção do processo organizado e racional
� utilização de documentação padrão
� Etapas: planejamento e projeto
3.1) Técnicas de Extração de Requisitos - JAD
Seis tipos de participantes
� líder
� engenheiro de requisitos
� executor
� representantes do usuário
� representantes de produtos de sw
� especialista
3.1) Técnicas de Extração de Requisitos - JAD
Sessão
Um ou mais
Encontros
requisitos
desenvolvidos e
documentados
Adaptação
Preparar
Organizar
Equipe e
Material
Finalização
Converte a
informação
final em um
documento
3.1) Técnicas de Extração de Requisitos - Prototipação
1. Determinar se o software é um bom candidato � Áreas de aplicação : interface, . . . � Complexidade : desenvolvimento de muito código
inviabiliza a prototipação (particionável) � Característica do cliente e gerente
2. Representação Resumida de Requisitos =>particionamento .
3. Um projeto rápido ( arquitetura e dados ).
-
5
3.1) Técnicas de Extração de Requisitos - Prototipação
4. Protótipo é criado e testado.� Técnicas de quarta geração � Reutilização de Software � Ferramentas de Videoconferência� Especialização formal + ambientes interativos.
5. Teste pelo usuário - sugestões (+importante).
6. Repetição de 4 e 5 até que todos os requisitos sejam formalizados; ou que o protótipo tenha evoluído.
4) Modelos para Especificação
� Representam a realidade
� Ajudam a organização e especificação mas não na extração
� Utilizam os princípios de abstração e decomposição – lidar com complexidade
� Existem diferentes tipos de especificação ao longo do desenvolvimento e em vários níveis.
4) Especificação pode ser
� Especificação dos requisitos – cliente edesenvolvedor
� Especificação de projeto geral –projetista e implementador
� Especificação de módulos –programadores que utilizam e implementam os módulos
4) Princípios- Especificação
� Separar funcionalidade de implementação
� Deve abranger o sistema do qual o sw é um componente
� Deve ser operacional (utilizável)
� Tolerante a incompleteza
� Consistente
4) Princípios - Especificação
� Realista
� Fracamente acoplada e localizada
� localizada: para que um único elemento tenha que ser modificado
� fracamente acoplada: permitir que adições e remoções sejam feitas facilmente
4) Modelos para Especificação
� Permitem a aplicação dos princípios de ES.
� Geralmente cobrem três dimensões do sistema
� dados (que dados ele mantém)
� funções (o que o sistema faz)
� comportamento (como ele se comporta –estados e eventos)
-
6
5) Diagrama de Fluxo de Dados – Modelo de Função
5) Diagrama de Fluxo de Dados – Modelo de Função
O DFD é um modelo que nos permite mostrar como a informação (dados) flui através de um sistema (ou seja, como ela vai sendo transformada ou organizada)� são recebidos
� podem ser armazenados
� podem fluir de um processo a outro
� podem ser transferidos para o ambiente externo
5) Diagrama de Fluxo de Dados – Modelo de Função
______
5) Diagrama de Fluxo de Dados (DFD) - Exemplo
Agente de
Viagem
Sistema de
Reserva
Sistema de
Cobrança
Preparação de
Bilhete
Cliente
Horário, dia, destino
Dados do vôo
Custo
Bilhete
Conta
Dados contábeis
Diretórios de vôo
Arquivo de Contabilidade
Informação sem vôos
5) Diagrama de Fluxo de Dados (DFD) – Como construir
5) Diagrama de Fluxo de Dados (DFD) – Como construir
-
7
5) Diagrama de Fluxo de Dados (DFD) – Como construir
� Particionar as funções em sub-funções:
� uma bolha deve ser particionada por vez
� rótulos dos fluxos, bolhas e arquivos devem ser significativos
� a continuidade da informação deve ser mantida
5) Diagrama de Fluxo de Dados (DFD) – Como construir
F
f4
A B
A
x
y
z
B
z
x
y
5) Diagrama de Fluxo de Dados (DFD) – Quando parar
� O DFD mostra as transformações de todas as entrada em saídas
� Os sub-processos não particionadospodem ser considerados elementares
� Cada bolha está conectada corretamente ao resto da rede
� As conexões foram minimizadas
5) Diagrama de Fluxo de Dados (DFD)
O DFD não mostra:
� descrição dos fluxos
� nem mecanismos de sincoronização
� comportamento
5) Diagrama de Fluxo de Dados – Extensão Tempo Real
Fluxo de dados que não é contínuotemp - max ≠ temp - medida.
Transforma controle ou eventos.
Representa eventos.
Armazena itens de controle ou eventos.
5) Diagrama de Fluxo de Dados – Extensão Tempo Real
Monitora ph
Mantém ph
constante
Muda ph
Processo de
Controle
Inicia
Pára
Ativa/Desativa
ph no nível desejado
Controle da Válvula de entrada
Ativa/Desativa
ph ativa
-
8
6) Modelo Entidade Relacionamento (MER)
� Dados descrevem coisas do mundo real.
� Itens de dados relacionados devem ser agrupados
� Ex: nome, endereço, RG são informações do sistema relacionados a uma entidade do mundo real que é o cliente.
� Ainda podemos ter relacionamentos entre entidades
6) Modelo Entidade Relacionamento (MER)DER – Diagrama Entidade Relacionamento
6) Modelo Entidade Relacionamento (MER)
DER – Diagrama Entidade Relacionamento Exemplo
6) Modelo Entidade Relacionamento (MER)
� Existem muitas ferramentas
� Fácil de entender
� Não diz como se forma o atributo CIC
� Não fica claro
7) Máquina de Estados Finitos (MEF)
� Os modelos de comportamento do sistema devem mostrar estados eventos que alteram esses estados
� Eventos são condições e ações para se mudar de estado.
7) Máquina de Estados Finitos (MEF)
Uma MEF é dada por: (S, s0, I, δ),
S – conjunto finito e não vazio de estados
S0∈S – estado inicial
I – conjunto finito de entradas (A (ações) e C (condições)) que podem ser nulas
δ:SxI → S - função de transição de estados
-
9
7) Máquina de Estados Finitos Diagrama de Estados (DTE)
7) Máquina de Estados Finitos Diagrama de Estados (DTE)
7) Máquina de Estados Finitos Diagrama de Estados (UML)
8) Dicionário de Dados (DD)
� Repositório de descrições de tudo que é utilizado em um modelo
� Vantagens: organização, resolução de ambigüidades e inconsistências, documentação, facilidade para relatórios, para alteração, etc
� Integração com outros modelos –ferramenta automatizada
8) Dicionário de Dados (DD) Elemento Fluxo de Dados
� nome
� sinônimo
� origem: referência do processo
� destino: referência do processo
� descrição
� informal
� formal
8) Dicionário de Dados (DD) Elemento Fluxo de Dados
Uma descrição mais formal representa o fluxo com a seguinte notação:
= é composto de
+ seqüência (e)
( ) opcional(pode ou não estarpresente)
{ } iteração – { }n n repetições
[ | ] ou exclusivo
* comentários
-
10
8) Dicionário de Dados (DD) Elemento Fluxo de Dados
Ex1)
nome = sobrenome + {int}n
0 + primeiro
sobrenome = string[30]
int = string[60], primeiro = string[30]
Ex2)
dados_pessoais = nome +endereço +
estado civil +(dependentes)
8) Dicionário de Dados (DD) Elemento Fluxo de Dados
Ex3)
exemplares = {exemplar}
exemplar = n_item+estado+nome_titulo
n_item = cod_biblioteca+n_exemplar
itens elementares de dados:
cod_biblioteca = string[2]
n_exemplar = inteiro
nome_titulo = string[60]
8) Dicionário de Dados (DD) Elemento Depósito de Dados
� referência
� descrição
� fluxos de entrada e saída
� conteúdo
8) Dicionário de Dados (DD) Elemento Processo (Bolhas)
� referência
� descrição
� fluxos de entrada e saída
� resumo lógico
8) Dicionário de Dados (DD) Elemento Entidade Externa
� nome
� descrição
� outras informações importantes
9) O Modelo de Objetos –Principais Conceitos
Objeto
� Abstração ou conceito do mundo real
� Encapsulamento de atributos e serviços
Na análise – identificamos objetos no domínio do problema
No projeto – pensamos em objetos para a solução
-
11
9) O Modelo de Objetos –Principais Conceitos
Classe
� Uma coleção ou agrupamento de um ou mais objetos que podem ser descritos com os mesmos objetos e serviços.
Ex: os objetos mesa e cadeira, podem ser agrupados na classe mobília
9) O Modelo de Objetos –Principais Conceitos
Atributo
� Característica, qualidade de um objeto ou classe.
� Seus valores servem para diferenciar objetos (Instâncias)
9) O Modelo de Objetos –Principais Conceitos
Ocultamento da Informação -Encapsulamento
� Cada componente do programa deve conter uma única decisão de projeto.
� A interface definida de forma a revelar o mínimo possível sobre o seu funcionamento interno.
9) O Modelo de Objetos –Principais Conceitos
Ocultamento da Informação -Encapsulamento
� Reduz efeitos colaterais, facilita reuso, manutenção e testes, entendimento, etc.
� Acessam-se dados de um objeto apenas com métodos do próprio objeto que funcionam como interface para outros objetos.
9) O Modelo de Objetos –Principais Conceitos
Associações entre classes e objetos
� relacionamentos entre as classes que em geral, representam a utilização de serviços e/ou a organização entre as mesmas.
� devem refletir o domínio do problema
9) O Modelo de Objetos –Principais Conceitos
Hierarquia Generalização/Especialização
� mostra generalizações de entidades do mundo real com características comuns e extensões destas características em casos especializados
� super-classe – mais genérica
sub-classe – mais específica
-
12
9) O Modelo de Objetos –Principais Conceitos
9) O Modelo de Objetos –Principais Conceitos
� Pode-se ter uma hierarquia ou um entrelaçamento
� Pode-se herança múltipla
� Atributos e serviços comuns devem ser colocados no nível superior
� Deve satisfazer 100% a regra is-a
9) O Modelo de Objetos –Principais Conceitos
_________
9) O Modelo de Objetos –Principais Conceitos
9) O Modelo de Objetos –Principais Conceitos
9) O Modelo de Objetos –Principais Conceitos
-
13
9) O Modelo de Objetos –Principais Conceitos
Agregação/Decomposição
� representa um composto e suas partes
� um inteiro pode ser decomposto em diferente partes, ou várias partes podem ser agregadas em um composto
9) O Modelo de Objetos –Principais Conceitos
9) O Modelo de Objetos –Principais Conceitos
Agregação pode ser:
� Composição: a parte pertence apenas a um único composto
� Compartilhamento: a parte pode pertencer a mais de um composto
9) O Modelo de Objetos –Principais Conceitos
9) O Modelo de Objetos –Principais Conceitos
Métodos ou ServiçosProcessamento realizado por um objeto que indica o seu comportamento, em função do recebimento de uma mensagem
MensagensAtivação de um método. Um objeto se utiliza de um serviço ou se comunica com outro objeto enviando uma mensagem
9) O Modelo de Objetos –Principais Conceitos
Ligação Dinâmica (late binding)
Mecanismo pelo qual se decide o destino de uma mensagem em tempo de execução
Ex: int (*f)(); a função só definida
i =f(); → durante a execução
-
14
9) O Modelo de Objetos –Principais Conceitos
Sobrecarga de operadores (Overloading)
Operações de mesmo nome, mas implementadas de maneira diferente
Ex: operações de adição, subtração implementadas diferentemente para real e inteiro
9) O Modelo de Objetos –Principais Conceitos
Polimorfismo
Possibilidade de uma função poder manipular valores com tipos (formas) diversas
Ex: function comp(L:lista):integer
↑
qualquer tipo de lista (genérico)
mesma implementação
9) O Modelo de Objetos –Principais Conceitos
9) O Modelo de Objetos –Principais Conceitos
Construtor/Destrutor
Função para criação/remoção de instâncias de objetos/classes
Overriding (ou Sobreposição)
Mecanismo para redefinir ou tornar um atributo não aplicável
9) O Modelo de Objetos –Principais Conceitos
9) O Modelo de Objetos –Principais Conceitos
-
15
9) O Modelo de Objetos –Diagrama de Classes
9) O Modelo de Objetos –Diagrama de Classes Como Construir
� Na fase de análise constrói-se primeiramente um diagrama de classes sem se preocupar em definir os métodos, ao qual chamaremos de Modelo Conceitual
� Na fase de projeto os métodos são adicionados e o Modelo Conceitual refinado gerando o Diagrama de Classes
10) O Modelo Formal
� Utilizam notações matemáticas e podem ser empregados em qualquer estágio da especificação de um sistema
� Utilizam � operadores relacionais: >,
-
16
10) O Modelo Formal
Ex3) especificar função localiza_exemplar(exemplar_disponível:string):string
Pré-condição∃ b ∈ biblioteca/
pertence(b.código, exemplar_disponível)
Pós-condição∃ b ∈ biblioteca/ (b.nome=localiza_exemplar(exemplar_diponível)
^ pertence(b.código, exemplar_disponível)
10) O Modelo Formal
Ex4) especificar que um exemplar estádisponível em apenas uma biblioteca e reservado apenas para disciplinas de sua área
∀ e ∈ exemplar
(∀ b1,b2 ∈ biblioteca (disponível (b1,e) ^ disponível (b2,e)) ⇒b1=b2))
^
(∀ d ∈ disciplina (reservado(d,e)) ⇒ area (d,e))
10) O Modelo Formal –Linguagem Z
� Baseada em teoria dos conjuntos e lógica de primeira ordem
� Constrói-se um esquema que agrupa declarações de variáveis e predicados que restrigem os valores dessas variáveis.
Ex: ______ x ________ Inível: F N decl. var.
declarações ______________
________________ 0∉Inível predicado
predicados
top related