Exemplo Aula

Prévia do material em texto

*
Laboratório de Programação 
	Projeto de Software – Eng. De Requisitos e UML
George Cabral
*
Definindo o Sucesso do Software 
Clientes satisfeitos
Eles estão satisfeitos quando você:
Atende às expectativas
Entrega no prazo
Entrega no orçamento
O Sucesso começa com a Gerência de Requisitos !!
*
Como os Projetos podem ter sucesso?
Análise do Problema
Entenda o problema
Obtenha concordância dos envolvidos 
Levantamento dos Requisitos
Identifique quem usará o sistema (atores)
Descubra como o sistema será usado (casos de uso)
Gerência de Requisitos
Especifique os requisitos completamente 
Gerencie expectativas, mudanças e erros
Controle o aumento do escopo
Defina a equipe e a mantenha informada
*
Fatores de Falha dos Projetos
 Objetivos não estavam claros
 Ignorar um grupo de clientes
 Omitir um grupo de requisitos
 Permitir inconsistências entre grupos de requisitos
 Aceitar um requisito ambíguo e inconsistente
 Requisitos e especificações incompletos
 Requisitos e especificações instáveis (mudanças)
 Aceitar requisito inadequado, incorreto, indefinido, ou impreciso
*
Mas o que são Requisitos?
Os requisitos de um sistema de computação constituem uma especificação das características e propriedades do sistema ou 
Uma descrição do que o sistema deve fazer, de como ele deve se comportar, bem como das suas restrições de operação.
É importante ressaltar que os requisitos descrevem "o que o sistema deve fazer"- e também "o que ele não deve fazer"- sem dizer "o como fazer".
*
Requisitos e Especificação
Requisito (IEEE)
Uma condição ou capacidade necessitada por um usuário para resolver um problema ou alcançar um objetivo
Uma condição ou capacidade que deve ser satisfeita por um sistema para satisfazer um contrato ou um padrão
Especificação:
descrição rigorosa e minuciosa das características que um material, uma obra, ou um serviço deverá apresentar
processo de representação dos requisitos de uma forma que leva à implementação bem-sucedida
*
Importância da Especificação Correta
Não importa quão bem projetado ou codificado está um programa, se ele for mal analisado e especificado desapontará o usuário e trará aborrecimentos ao desenvolvedor
*
Análise de Requisitos
Entendimento
do domínio
Coleta de
requisitos
Classificação
Definição e
especificação
de requisitos
Resolução
de conflito
Atrib. Prioridade
Validação
dos requisitos
Entrada do
processo
Documento
de requisitos
1
2
3
4
5
6
7
8
*
Entendimento do Domínio
Desenvolver sistemas envolve domínios além de software e hardware
Podemos ter que entender sobre
Contabilidade
Saúde
Supermercados
Mercado
Etc.
*
Coleta de Requisitos
A coleta de requisitos é feita através de técnicas
Nesta etapa, os requisitos são simplesmente documentados à medida que são coletados
Resulta em documento preliminar (draft)
*
Classificação dos Requisitos
Esta etapa consiste basicamente em agrupar os diversos requisitos coletados em categorias bem-definidos
Por exemplo
Requisitos Funcionais: descrevem o comportamento do sistema, suas ações para cada entrada, ou seja, é aquilo que descreve o que tem que ser feito pelo sistema.
Requisitos não funcionais: expressam como deve ser feito. Em geral se relacionam com padrões de qualidade como confiabilidade, performance, robustez, etc.
*
Problema da Análise de Requisitos
Stakeholders em geral não sabem o que querem
Stakeholders expressam requisitos em sua terminologia
Stakeholders diferentes podem gerar requisitos conflitantes
*
Problema da Análise de Requisitos
Fatores políticos e organizacionais podem influenciar os requisitos do sistema
Requisitos mudam durante o processo de análise. Stakeholders novos podem surgir e o ambiente de trabalho muda
*
Resolução de Conflitos
É normal que ocorram requisitos conflitantes
Por exemplo
R-23: O sistema deve ...
R-45: O sistema não deve ...
Cliente/usuário deve ser consultado para resolver conflitos (ambigüidades)
*
Atribuição de Prioridade
Alguns requisitos são mais urgentes que outros
É essencial determinar a prioridade dos requisitos junto ao cliente
Requisitos de maior prioridade são considerados em primeiro lugar
*
Prioridade
Requisitos podem ser vistos em três classes distintas
Essenciais
Importantes
Desejáveis
Em princípio, sistema deve resolver todos os requisitos de essenciais para desejáveis
*
Exemplo de Prioridade
[RF001] Consulta X ao B.D. deve retornar dados A, B, C
Prioridade: Essencial
[RNF001] Consulta X ao B.D. deve visualizar dados segundo padrão Y
Prioridade: Importante
[RNF010] Consulta X ao B.D. deve usar cores azuis nos resultados
Prioridade: Desejável
*
Validação dos Requisitos
Será que realmente entendi o que o cliente deseja?
Devo me certificar de que não houve falha em nossa interação (comunicação)
Há diversas técnicas de validação
*
Validação de Requisitos
Demonstrar que os requisitos definem o sistema que o cliente realmente deseja
Custos com erros de requisitos são altos
Consertar um erro de requisitos após entrega do sistema pode custar mais de 100 vezes o custo de um erro de implementação
*
Técnicas de Validação de Requisitos
Revisões de Requisitos
Análise manual sistemática dos requisitos
Prototipação
Uso de modelo executável do sistema para avaliar requisitos
Geração de Casos de Teste
Desenvolver testes específicos para os requisitos para avaliá-los
*
Gerenciamento de Requisitos
Gerenciamento de requisitos é o processo de controlar as mudanças dos requisitos durante
O processo da engenharia de requisitos
E desenvolvimento do sistema
*
Gerenciamento de Requisitos
Requisitos são inevitavelmente incompletos e inconsistentes
Requisitos novos surgem durante o processo de acordo com mudanças nas necessidades do negócio e um entendimento melhor do sistema é desenvolvido
Diferentes pontos de vista têm diferentes requisitos e esses geralmente são contraditórios
*
Rastreamento
Responsável por dependências entre requisitos, suas origens e projeto do sistema
Rastreamento de Origem
Associação entre requisitos e stakeholders que propuseram tais requisitos
*
Rastreamento
Rastreamento de Requisitos
Associação entre requisitos dependentes
Rastreamento de Projeto
Associação dos requisitos com o projeto
Usar hipertexto ou referência cruzada
Ou matriz de rastreamento
*
Estrutura de um Documento de Requisitos
1. Introdução
2. Definição dos Requisitos do Usuário
3. Especificação dos Requisitos do Sistema
4. Arquitetura do Sistema
5. Modelos do Sistema
6. Evolução do Sistema
7. Apêndices
8. Índice
*
Documento de Requisitos
Fonte: IEEE/ANSI (830-1998)
1. Introdução
1.1 Propósito do documento
1.2 Escopo do sistema
1.3 Glossário, acrônimos e abreviaturas
1.4 Referências
1.5 Descrição do resto do documento
*
Documento de Requisitos
Fonte: IEEE/ANSI (830-1998)
2. Descrição geral
2.1 Perspectiva do produto 
2.2 Funções do produto
2.3 Características dos usuários
2.4 Restrições gerais
2.5 dependências
*
Documento de Requisitos
Fonte: IEEE/ANSI (830-1998)
3. Requisitos específicos
requisitos funcionais, não-funcionais, GUI com o usuário: 
funcionalidade, interfaces externas, desempenho, restrições, atributos do sistema, caract. qualidade, ...
*
Documento de Requisitos
4. Arquitetura do Sistema
5. Modelos do Sistema
Diagrama de Atores
Modelo de Caso de Uso
Modelo de Análise
Modelo de Projeto
Diagrama de Pacotes
6. Evolução do Sistema (Futuro)
7. Apêndices
8. Índice
*
Abreviações e Glossário
*
UML
*
O que é um modelo?
Construímos modelos para compreender melhor o sistema que estamos desenvolvendo.
Um modelo é uma simplificação da realidade.
Um modelo pode ser estrutural ou comportamental.
*
O que é um modelo?
*O que é um modelo?
*
Por que modelar software?
Ajuda a ter uma visão geral do sistema
Permite especificar a estrutura e o comportamento do sistema
Proporciona um guia para a construção do sistema
Documenta as decisões tomadas
*
O que é a UML?
Unified Modeling Language (UML) é...
...	uma linguagem gráfica para visualizar, especificar, construir e documentar os artefatos de um sistema de software.
...	resultado da unificação das notações utilizadas nos métodos Booch, OMT (Object Modeling Technique) e OOSE (Object-Oriented Software Engineering).
...	adotada por grande parte da indústria de software e por fornecedores de ferramentas CASE como linguagem padrão de modelagem.
…	utilizada com qualquer processo de desenvolvimento já que é independente dele. 
*
A UML é uma Linguagem para Visualização
No processo de desenvolvimento de sistemas de software, é quase impossível a visualização de toda a estrutura de um sistema sem o uso de modelos que a represente.
A UML fornece os símbolos gráficos para a representação de artefatos de software.
Por trás de cada símbolo empregado na notação da UML, existe uma sintaxe e uma semântica bem-definidas.
Dessa maneira, um desenvolvedor poderá usar a UML para escrever seu modelo, diminuindo a ambigüidade em sua interpretação.
*
A UML é uma Linguagem para Construção
Os modelos de UML podem ser diretamente ”traduzidos” para várias linguagens de programação.
Isso significa que é possível mapear os modelos da UML para linguagens de programação tais como, Java, C++ e Visual Basic.
Esse mapeamento permite a realização de uma engenharia de produção: geração de código a partir de um modelo em UML.
O processo inverso, a engenharia reversa, também é possível, com a reconstrução de um modelo a partir de sua implementação.
*
A UML é uma Linguagem para Documentação
…
Cada modelo criado é um artefato do software
*
Uma linguagem de diagramas
Diagramas de Classe
Diagramas de Colaboração
Diagramas de Seqüência
Diagramas de Estado
Diagramas de Atividade
Diagramas de Objetos
Diagrama de Deployment
Diagramas de Componentes
Diagrama de Casos de Uso
Modelos
Ponto de Vista Estático
Ponto de Vista Dinâmico
*
Casos de Uso
Este caso de uso é responsável por autenticar um usuário do sistema.
Pré-condição: nenhuma
Pós-condição: um usuário válido é logado e sua sessão é registrada no sistema.
Fluxo de eventos principal
1. O cliente informa login e senha.
2. O sistema verifica se o login e a senha são válidos (verifica-se se o login e senha pertencem a uma conta).
3. O sistema registra o início de uma sessão de uso.
Fluxos secundários
- No passo 2, se o login ou a senha forem inválidos, o sistema exibe uma mensagem e volta ao passo 1.
Descrição 
Narrativa
*
Diagrama de Casos de Uso
Sistema de controle de pré-requisitos
*
Diagrama de Classes
+confirmar()
+cancelar()
-calcularTotal():Currency
gerarNovoCodigo: String
-codigo: Integer
-dataRecebido
-total: Currency
Pedido
#creditoPermitido: Currency
#nivelCredibilidade()
-nome: String
-endereco: String
-dataPrimeiraCompra: Date
-dataUltimaCompra: Date
-totalComprado: Currency
Cliente
-quantidade: Integer
-preco: Currency
-emEstoque: Boolean
Item de Pedido
nomeContato: String
telefones[1..10]: String
CGC: String
FAX[1..3]: String
Cliente pessoa-jurídica
colocarListaNegra()
nome: String
CPF: String
numCartaoCredito
Cliente pessoa-física
Empregado
Produto
*
representante
de vendas
*
IPessoa
itens
0..*
1
 faz
*
Diagrama de Objetos
p2: Professor
matricula: "205-6712-09"
nome: "Jaelson Castro"
p1: Professor
codCurso: "IF291"
descrição: "MPS"
codTurma: I7
: Curso
codCurso: "IF185"
descrição: "AER"
codTurma: I6
: Curso
matricula: "219846534"
nome: "Nelson Mandella"
:aluno
matricula: "562746134"
nome: "John Major"
:aluno
: Aluno
: Aluno
: Aluno
: Aluno
c1: Curso
c2: Curso
c3: Curso
Bill
: Aluno
: Aluno
Lewinsky
*
Diagrama de Sequência
*
Diagrama de Colaboração
*
Diagrama de Estados
*
Diagrama de atividades
*
Diagrama de Componentes
*
Diagrama de Implantação
*
Atores: Especialização
É possível definir tipos gerais de atores e especializá-los usando o relacionamento de especialização
*
The Unified Modelling Language User Guide (Grady Booch)
The Unified Modelling Language Reference Manual (James Rumbaugh)
The Unified Software Development Process (Ivar Jacobson)
UML Distilled (Martin Fowler)
Bibliografia
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*