Professor Mário Dantas

56
Professor Mário Dantas ANÁLISE ORIENTADA A OBJETOS Set/2010

description

Análise Orientada a Objetos. Set/2010. Professor Mário Dantas. Aula 03 - Agenda. Fase de Concepção Engenharia de Requisitos. Fase de Concepção. - PowerPoint PPT Presentation

Transcript of Professor Mário Dantas

Page 1: Professor  Mário Dantas

Professor Mário Dantas

ANÁLISE ORIENTADA A OBJETOSSet/2010

Page 2: Professor  Mário Dantas

Aula 03 - Agenda Fase de Concepção Engenharia de Requisitos

Page 3: Professor  Mário Dantas

Fase de Concepção A fase de concepção é uma etapa na

qual o analista vai buscar as primeiras informações sobre o sistema a ser desenvolvido. Nesta etapa, assume-se pouco conhecimento do analista sobre o sistema e uma grande interação com o usuário e o cliente (WAZLAWICK, 2004).

Page 4: Professor  Mário Dantas

Fase de Concepção Os artefatos dessa fase são ainda

desestruturados, isto é, não são necessariamente completos e organizados. O objetivo é descobrir se vale a pena fazer a análise, mas sem fazer a análise propriamente dita (WAZLAWICK, 2004).

Page 5: Professor  Mário Dantas

Passo inicial curto, no qual se explora as seguintes questões:

Qual é a visão e o caso de negócio para o projeto?

Ele é viável? Devemos construir ou comprar? Estimativa de custo aproximada: qual a

ordem de grandeza? Devemos continuar ou parar?

Page 6: Professor  Mário Dantas

Fase de Concepção A concepção, em uma frase:

Conceber o escopo do produto, a visão e o caso de negócio.

O problema principal a ser resolvido, em duas frases: Os interessados no projeto do sistema têm

um consenso básico sobre a visão do projeto?

Vale a pena investir em uma investigação séria?

Page 7: Professor  Mário Dantas

Fase de Concepção De acordo com Waslawick (2004), a fase

de concepção pode ser dividida em três partes: Levantamento de requisitos; Organização dos requisitos; Planejamento do desenvolvimento.

Page 8: Professor  Mário Dantas

Fase de Concepção Documentos gerados durante o

levantamento de requisitos: Visão geral do sistema ou sumário

executivo; Requisitos funcionais e não funcionais;

Page 9: Professor  Mário Dantas

Fase de Concepção Os documentos acima são fundamentais

para o entendimento da fase de concepção, ainda existem outros artefatos que podem ser produzidos nessa fase, tais como: O glossário; Análise de riscos e seu controle; Protótipos;

Page 10: Professor  Mário Dantas

Fase de Concepção Visão geral do sistema

A visão geral do sistema é um documento de texto em formato livre, na qual deve escrever aquilo que se conseguiu descobrir de relevante sobre o sistema após as conversas com os clientes e usuários.

Page 11: Professor  Mário Dantas

Sistema de Vídeo locadora Visão Geral do Sistema

É proposto o desenvolvimento de um sistema de controle de videolocadora, que vai informatizar as funções de empréstimo, devolução e reserva de filmes. O objetivo do sistema é agilizar o processo de empréstimo e garantir maior segurança, ao mesmo tempo possibilitar um melhor controle das informações por parte da gerência. Deverão ser gerados relatórios de empréstimos por cliente, empréstimos por cliente, empréstimos por filme e empréstimos por mês. O sistema deverá calcular automaticamente o valor dos pagamentos a serem efetuados em cada empréstimos, inclusive multas e descontos devidos. A cada devolução de filmes corresponderá um pagamento, não sendo possível trabalhar com sistema de créditos. A impossibilidade de efetuar um pagamento deve deixar o cliente suspenso, ou seja, impossibilitado de tomar emprestados novos filmes até saldar a dívida.

Page 12: Professor  Mário Dantas

Requisitos

Page 13: Professor  Mário Dantas

Definições Pfleeger (2004), um requisito é uma

característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir os seus objetivos.

Sommerville (2007), as descrições das funções e restrições são os requisitos do sistema.

SWEBOK (2004), um requisito é descrito como uma propriedade que o software deve exibir para resolver algum problema no mundo real.

Page 14: Professor  Mário Dantas

Definições Uma condição ou capacidade necessária

para um usuário resolver um problema ou alcançar um objetivo.

Uma condição ou uma capacidade que deve ser alcançada ou estar presente em um sistema para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto.

Page 15: Professor  Mário Dantas

Importância dos Requisitos Resultados de um estudo feito pelo

Standish Group em 350 companhias e 8000 projetos de software (Pfleeger, 2004): 31% dos projetos cancelados antes de

estarem completos Em pequenas companhias, somente 16% dos

projetos foram entregues no prazo e no orçamento inicialmente estabelecido

Em grandes companhias, apenas 9% estão de acordo com esses critérios

Page 16: Professor  Mário Dantas

Importância dos Requisitos O Standish Group classificou os projetos em

3 categorias: Sucesso (16,2%) : Cobre todas as

funcionalidades, em tempo e dentro do custo previsto (cronograma e orçamento)

Problemático (52,7%) : Não cobre todas as funcionalidades exigidas, custo aumentado e/ou com entregas em atraso.

Fracasso (31,1%): Cancelado durante o desenvolvimento

Page 17: Professor  Mário Dantas

Desafios Compreensão do domínio do problema. Comunicação efetiva com reais usuários

e clientes do sistema. Evolução contínua dos requisitos do

sistema.

Page 18: Professor  Mário Dantas

Domínio O termo, no contexto da engenharia de

software, é utilizado para denotar ou agrupar um conjunto de sistemas ou de áreas funcionais, que exibem características similares.

É definido por um conjunto de características que descrevem uma família de problemas para os quais uma determinada aplicação pretende dar solução.

Page 19: Professor  Mário Dantas

Especificação de Requisitos Estabelece uma base de concordância

entre o cliente e o fornecedor sobre o que o software fará.

Fornece uma referência para a validação do produto final (uma especificação de requisitos de alta qualidade é pré-requisito para um software de alta qualidade).

Reduz o custo do software.

Page 20: Professor  Mário Dantas

Por que precisamos de requisitos?

Para entender o que o cliente quer

Para documentar o que o cliente quer

Para assegurar a qualidade e a satisfação do cliente

Para entender o problema do negócio

Para documentar o escopo do projeto e definir suas restriçõesPara definir critérios de aceitação e gerenciar as expectativas do cliente

Page 21: Professor  Mário Dantas

Engenharia de Requisitos

Page 22: Professor  Mário Dantas

Definição Sommerville (2003), Engenharia de

Requisitos é o processo de descobrir, analisar, documentar e verificar as funções e restrições do sistema.

Page 23: Professor  Mário Dantas

Engenharia de Requisitos Descreve as atividades relacionadas à

investigação e definição de escopo de um sistema de software.

Processo sistemático de produção de requisitos por meio de atividades cooperativas de análise em que os resultados são documentados em uma variedade de formatos e a precisão das observações é constantemente verificada.

Page 24: Professor  Mário Dantas

Questionamentos Típicos Como seguir um processo pré-

estabelecido se tantos fatores são desconhecidos no início do desenvolvimento do software?

Os fatores desconhecidos serão melhor elucidados e os riscos serão minimizados com um processo sistemático, iterativo e incremental.

Page 25: Professor  Mário Dantas

Questionamentos Típicos Quantas iterações são necessárias para

verificar a correção e a precisão das observações?

A quantidade de iterações ideal será aquela suficiente para que cliente e fornecedor sintam-se seguros e concordem com o que está definido, mesmo com o que surgir de novo e for aceito para o escopo do projeto.

Page 26: Professor  Mário Dantas

Questionamentos Típicos Quais representações e notações devem

ser usadas na captura e documentação dos requisitos?

As representações e notações devem estar previstas no processo de software e no método adotado por esse processo. Tipicamente, são usados casos de uso e suas especificações .

Page 27: Professor  Mário Dantas

Questionamentos Típicos Qual o nível de precisão e formalidade

dos requisitos? Dependerá de quão crítico é o sistema e

das características do cliente.

Page 28: Professor  Mário Dantas

Questionamentos Típicos Como sabemos que chegamos ao final

do processo? Similarmente à quantidade de iterações,

até que haja uma base sólida de concordância entre o desenvolvedor e o cliente

Page 29: Professor  Mário Dantas

Visão Geral

Produção de Requisitos

Levantamento

Registro

Obtenção de Comprometimento

Verificação

Gerência de RequisitosControle de Mudança

Gerência de Configuração

Rastreabilidade

Gerência de Qualidade de

Requisitos

Engenharia de Requisitos

Page 30: Professor  Mário Dantas

Síntese dos Objetivos Estabelecer uma visão comum entre o cliente e

a equipe de projeto sobre os requisitos que serão atendidos;

Registrar e acompanhar requisitos ao longo de todo o desenvolvimento;

Documentar e controlar os requisitos para estabelecer uma base para uso gerencial e da equipe de desenvolvimento;

Manter planos, artefatos e atividades de software coerentes com os requisitos alocados.

Page 31: Professor  Mário Dantas

Uma Última Questão O que acontece se:

O usuário mudar de idéia em relação a uma funcionalidade?

O ambiente mudar? O usuário perceber novas possibilidades na

automação? O engenheiro de requisitos (ou analista)

não ter entendido corretamente a necessidade do usuário?

Page 32: Professor  Mário Dantas

Gerência de Mudança É preciso gerenciar as mudanças! Mudanças em requisitos ao longo do

processo fazem parte do desenvolvimento de software.

Alterações em requisitos podem implicar mudanças em artefatos de projeto, de código, casos de testes, etc.

Page 33: Professor  Mário Dantas

Identificação dos Requisitos Trata-se da identificação dos requisitos em

si para formação da idéia inicial do sistema e compreensão do domínio do problema.

“Trabalhe com os usuários e não contra eles” (AMBLER).

“Temos que aceitar a instabilidade dos requisitos como um fato da vida, e não condená-la como o resultado de um raciocínio mal conduzido” (COAD).

Page 34: Professor  Mário Dantas

Ações com Foco no Usuário Identificar Objetivos de Negócio (Por que

desenvolver algo?) Identificar Stakeholders (Quem está

envolvido?) Obter diferentes Pontos de Vista (Com que

os stakeholders estão preocupados? Existem conflitos?)

Resolver Conflitos Identificar Cenários (Quais resultados as

pessoas desejam? Sob que circunstâncias?)

Page 35: Professor  Mário Dantas

Problemas Comuns Escopo: O limite do sistema é mal definido, ou

detalhes técnicos desnecessários confundem os objetivos globais

Entendimento: Os clientes e usuários não estão completamente certos do que é necessário, não tem pleno entendimento do domínio do problema, têm dificuldade de comunicar as necessidades, têm pouca compreensão das capacidades

Volatilidade: Os requisitos mudam com o tempo

Page 36: Professor  Mário Dantas

Desafios a Suplantar Falta de conhecimento do usuário das

suas reais necessidades e do que um produto de software pode oferecer

•Falta de conhecimento do desenvolvedor sobre o domínio do problema

Page 37: Professor  Mário Dantas

Habilidades do Desenvolvedor Dominar o processo de produção de

requisitos e suas técnicas Ouvir o que os usuários têm a dizer sem

induzi-los a aceitar visões e interpretações já vivenciadas pela equipe

Comunicar adequadamente aos usuários e clientes a evolução do trabalho e suas limitações

A produção de requisitos é um processo social

Page 38: Professor  Mário Dantas

Classificação de Requisitos Classificação Comum:

Requisitos Funcionais Requisitos Não Funcionais Requisitos do Domínio

Page 39: Professor  Mário Dantas

Outras Classificações para Requisitos

Requisito do usuário: declarações sobre as funções que o sistema deve oferecer

Requisito do sistema: detalhamento das funções e das restrições (contrato entre cliente e desenvolvedor)

Requisito do projeto: define como o projeto deve ser conduzido e que artefatos devem ser produzidos (escopo do projeto).

Page 40: Professor  Mário Dantas

Requisitos Funcionais Requisitos diretamente ligados ao

comportamento do software Descrevem as funções que o software

deve executar Descrevem as interações entre o

sistema e seu ambiente

“O software deve permitir que o atendente consulte o relatório com os resultados dos testes clínicos de um paciente”.

Page 41: Professor  Mário Dantas

Exemplos [RFO1] O software deve permitir que o

atendente efetue cadastro de clientes. [RFO2] O software deve permitir que o

caixa efetue o registro de itens vendidos. [RFO3] O software deve permitir que o

administrador gere o um relatório de vendas por mês.

Page 42: Professor  Mário Dantas

Exercícios Escreva três requisitos funcionais para

sistemas a serem desenvolvidos para os seguintes domínios:

Vídeo Locadora Apoio Inteligente à Análise de Risco para

Bolsa de Valores Sistema de Caixa de Auto-atendimento

de um Sistema Bancário.

Page 43: Professor  Mário Dantas

Uma Solução Possível Vídeo Locadora:

O software deve permitir que o administrador efetue o cadastro de clientes

O software deve permitir que o administrador efetue o cadastro de DVDs

O software deve permitir que o atendente efetue o registro de DVDs alocados

Auto-atendimento Bancário: O software deve permitir que o cliente consulte seu

extrato O software deve permitir que o cliente efetue saque; O software deve permitir que o cliente efetue o

pagamento da fatura do cartão de crédito.

Page 44: Professor  Mário Dantas

Soluções Possíveis Apoio Inteligente à Análise de Risco para

Bolsa de Valores

O domínio da aplicação pode dificultar – e muito – o trabalho de produção dos requisitos!

Page 45: Professor  Mário Dantas

Requisitos Não Funcionais São requisitos que expressam condições

que o software deve atender ou qualidades específicas que o software deve ter.

Em vez de informar o que o sistema fará, os requisitos não funcionais impõem restrições ao sistema.

Podem ser mais críticos que requisitos funcionais, chegando a tornar um sistema impossível ou inútil.

Page 46: Professor  Mário Dantas

Exemplos “As consultas ao sistema devem ser

respondidas rapidamente” “As consultas ao sistema devem ser

respondidas em menos de três segundos”

Requisitos Não Funcionais devem ser mensuráveis e estar associados a uma

forma de medida ou referência

Page 47: Professor  Mário Dantas

Medidas para Requisitos Não Funcionais

Propriedade MedidaVelocidade Transações processadas por

segundoTempo de resposta do usuário/evento

Tamanho KbytesNum. De chips de RAM

Facilidade Tempo de treinamentoNum. Quadros de ajuda

Confiabilidade Tempo médio de falhasProbabilidade de indisponibilidadeTaxa de ocorrência de falhas

Robustez Tempo de reinício após a falhaPercentual de eventos causando falha

Portabilidade Num. de sistemas destino

Page 48: Professor  Mário Dantas

Classificação dos RNF RNF do Produto: Produto deve comportar-

se de forma particular (velocidade de execução, confiabilidade, etc.)

RNF Organizacionais: Conseqüência de políticas e procedimentos organizacionais (padrões de processo usados, requisitos de implementação, etc.)

RNF Externos: Conseqüência de fatores externos ao sistema e ao processo de desenvolvimento (legislação, etc.)

Page 49: Professor  Mário Dantas

RNF do Produto RNF de usabilidade: usuários devem ser capazes de usar

as funções do sistema após duas horas de treinamento RNF de confiabilidade: o sistema deve estar disponível

99% das vezes RNF de segurança: o acesso aos dados deve ser

protegido, conforme RN RNF de desempenho: o sistema deve processar n

requisições por segundo RNF de capacidade: o sistema deve suportar n usuários

concorrentemente RNF de portabilidade: o sistema deve rodar nas

plataformas X e Y

Page 50: Professor  Mário Dantas

RNF Organizacionais São procedentes de políticas e procedimentos

nas organizações do cliente e do desenvolvedor: RNF de entrega: um relatório de progresso

deve ser entregue a cada duas semanas RNF de implementação: o sistema deve ser

implementado na linguagem Java RNF de padrões e métodos de

desenvolvimento: uso de métodos orientados a objetos; desenvolvimento utilizando a ferramenta X

Page 51: Professor  Mário Dantas

RNF Externos Impostos tanto ao produto quanto ao processo

de desenvolvimento em função do ambiente no qual o sistema é desenvolvido:

RNF de interoperabilidade: o sistema deve interagir com os sistemas X e Y

RNF de restrições éticas: o sistema não deverá revelar aos operadores nenhuma informação pessoal dos clientes

RNF de restrições legais: o sistema deverá armazenar as informações de acordo com a Lei número XXYY de ZZ

Page 52: Professor  Mário Dantas

Requisitos de Domínio Derivados do domínio da aplicação e

descrevem características do sistema e qualidades que refletem o domínio

Podem ser gerar requisitos funcionais novos ou restrições sobre os existentes

São regras de negócio (RN)

Page 53: Professor  Mário Dantas

Problemas Entendimento

Requisitos são descritos na linguagem do domínio da aplicação

Não é entendido pelos engenheiros de software que vão desenvolver a aplicação

Aspectos Implícitos Especialistas no domínio entendem a área

tão bem que assumem que os requisitos estão claros para os desenvolvedores

Page 54: Professor  Mário Dantas

Exemplos [RN1] Os campos referentes a “Orçamento

Projeto Vinculado” só estarão ativos se o tipo de projeto for Vinculado.

[RN2] O campo Valor Total Orçado para o Projeto é calculado somando-se os valores definidos para todas as rubricas incluídas no orçamento do projeto, seja ele vinculado ou não-vinculado.

[RN3] A soma dos percentuais a ser distribuído entre os fundos incluídos no plano de aplicação deve ser entre 0 e 100%

Page 55: Professor  Mário Dantas

Exercício Forneça alguns exemplos de requisitos

de domínio (RN) para:1. Vídeo Locadora2. Sistema de Auto-atendimento Bancário

Page 56: Professor  Mário Dantas

Respostas Vídeo locadora:

[RN1] O software deve permitir que o cliente alugue no máximo 2 filmes na primeira locação.

Sistema de Auto-atendimento Bancário: [RN1] O cliente pode sacar o valor máximo

de R$ 100,00 por dia.