A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Técnicas e Projeto de Sistemas André Mesquita Rincon Engenharia de requisitos Técnico Subsequente – Módulo.

Apresentações semelhantes


Apresentação em tema: "Técnicas e Projeto de Sistemas André Mesquita Rincon Engenharia de requisitos Técnico Subsequente – Módulo."— Transcrição da apresentação:

1 Técnicas e Projeto de Sistemas André Mesquita Rincon Engenharia de requisitos Técnico Subsequente – Módulo III (08/03/2010)

2 Engenharia de requisitos o Introdução o Uma das principais medidas do sucesso de um software é o grau no qual ele atende aos objetivos e requisitos para os quais foi construído

3 Engenharia de requisitos o Introdução o A Engenharia de Requisitos é o processo de identificar todos os envolvidos (stakeholders), descobrir seus objetivos e necessidades, e documentá-los de forma adequada para análise, comunicação e posterior implementação o Área do conhecimento do SWEBOK responsável pela elicitação, análise, especificação e validação dos requisitos o O SWEBOK a denomina apenas Requisitos

4 Engenharia de requisitos o Definição o Requisitos expressam necessidades e limitações sobre um produto que soluciona um problema do mundo real o São uma combinação complexa de necessidades de diferentes pessoas em diferentes níveis de uma organização e do ambiente em que o software irá operar o São parâmetros do produto que será desenvolvido (i.e.: requisitos sobre o que o software deve fazer) o Requisitos devem ser definidos com clareza e de forma quantificável

5 Engenharia de requisitos o Tipos de requisitos o Requisitos são classificados em: o Funcionais e não funcionais o Requisitos Funcionais o Representam as funções que o software deve executar o Indicam (apontam) as funções que o sistema deve fornecer e como o sistema deve se comportar em determinadas situações

6 Engenharia de requisitos o Tipos de requisitos o Requisitos não funcionais o Descrevem restrições sobre as funções oferecidas, tais como: o Restrições de uso de recursos, requisitos de qualidade, de desempenho, de segurança, de manutenibilidade, de usabilidade, etc...

7 Engenharia de requisitos o Processo de requisitos o Possui atividades como elicitar (levantar), analisar, documentar e validar requisitos o Ocorre desde o início do projeto e é refinado até o final dele o Identifica os requisitos como itens de configuração e os gerencia o Atores envolvidos no processo de requisitos Analista de negócios Analista de sistemas Desenvolvedor Engenheiro de testes

8 Engenharia de requisitos o Processo de requisitos o Os processos de engenharia de requisitos variam de uma organização para outra, mas a maioria dos processos de Engenharia de Requisitos é composta das seguintes atividades: o Elicitação (levantamento) de requisitos o Análise de requisitos o Especificação de requisitos o Validação de requisitos

9 Engenharia de requisitos o Elicitação (levantamento) o Preocupa-se tanto com onde os requisitos podem ser encontrados e como obtê-los o Fontes de requisitos o Objetivos do negócio o Domínio da aplicação o Pontos de vista de todos os Stakeholders (diferentes níveis da organização) o Ambiente de operação o Organização (estrutura, cultura e política)

10 Engenharia de requisitos o Elicitação (levantamento) – técnicas o Entrevistas: meio mais tradicional e seu sucesso depende muito da forma como ela é conduzida o Cenários: contexto operacional do usuário (notação: casos de uso) o Prototipação: permite ao usuário uma visão melhor das informações que ele necessita o Reunião com mediadores: identificar pontos de conflito e aplicar técnicas como brainstorming com várias pessoas pode ser mais proveitoso o Observação: imersão no ambiente dos usuários possibilita um entendimento melhor de algumas funções (ou operações)

11 Engenharia de requisitos o Elicitação (levantamento) – técnicas o Algumas dificuldades geralmente são encontradas: o Dificuldades dos usuários em descrever suas funções o Falta de vontade em cooperar o O engenheiro deve entender que não é uma atividade passiva e que, nesta fase, os usuários, clientes e especialistas de domínio identificados devem trabalhar junto com os engenheiros de requisitos para levantar, articular e entender a organização como um todo, o domínio da aplicação, os processos de negócio específicos, as necessidades que o software deve atender e os problemas e deficiências dos sistemas atuais o Sistema atual não referencia apenas softwares atuais

12 Engenharia de requisitos o Elicitação (levantamento) – técnicas auxiliares o O&M o Elaboração de funcionogramas e fluxogramas do ambiente de operação o Visa entender como a organização atua sem a presença de um sistema, pois auxilia no entendimento dos objetivos e funcionalidades do software o Exemplo 1 – Funcionograma o Exemplo 2 – Fluxograma sem software o Exemplo 3 – Fluxograma com software

13 Micro-atividade 1.Divisão dos grupos em: entrevistadores e 1 cliente (5 minutos) 2.Os entrevistadores deverão elaborar, no mínimo, três perguntas sobre o sistema a ser modelado por vocês (10 minutos) 3.Realizar a entrevista e documentar as respostas (15 minutos)

14 Engenharia de requisitos o Processo de requisitos o Os processos de engenharia de requisitos variam de uma organização para outra, mas a maioria dos processos de Engenharia de Requisitos é composta das seguintes atividades: o Elicitação (levantamento) de requisitos o Análise de requisitos o Especificação de requisitos o Validação de requisitos

15 Engenharia de requisitos o Análise de requisitos o Complementa a elicitação o Detectar e resolver conflito entre requisitos o Stakeholders com interesses diferentes (incompatíveis) o Deve-se evitar decisão unilateral por parte do engenheiro o Questões contratuais podem obrigar a presença do cliente o Casos maiores podem ser analisados na fase de validação

16 Engenharia de requisitos o Análise de requisitos o Estabelecer um conjunto de requisitos consistentes e sem ambigüidades, que possa ser usado como base para o desenvolvimento do software o Deve-se classificar os requisitos em: Funcionais e não funcionais o Para esta atividade, alguns tipos de modelos podem ser construídos o Um modelo é uma representação de alguma coisa do mundo real, uma abstração da realidade, e, portanto, representa uma seleção de características do mundo real relevantes para o propósito do sistema em questão

17 Engenharia de requisitos o Análise de requisitos o São fundamentais no desenvolvimento de sistemas e são construídos para: o Auxiliar no estudo do comportamento do sistema o Facilitar a comunicação entre os componentes da equipe e clientes e usuários o Facilitar a discussão de correções e modificações com o usuário o Formar a documentação do sistema

18 Engenharia de requisitos o Análise de requisitos o Como foi dito, os modelos possuem níveis de abstração o O nível de abstração de um modelo diz respeito ao grau de detalhamento com que as características do sistema são representadas o No caso do desenvolvimento de sistemas, geralmente, são considerados três níveis: o Conceitual o Lógico o Físico

19 Engenharia de requisitos o Análise de requisitos – níveis de abstração o Conceitual o Considera características do sistema independentes do ambiente computacional no qual o sistema será implementado o Essas características são dependentes unicamente das necessidades do usuário o Modelos conceituais são construídos na atividade de análise de requisitos o Fatores que influenciam na escolha do modelo: natureza do problema, experiência do engenheiro, requisitos do processo e a disponibilidade de ferramentas e métodos o A utilização de uma notação aceitável pela maioria pode trazer benefícios (UML)

20 Engenharia de requisitos o Análise de requisitos – níveis de abstração o Lógico o Características dependentes de um determinado tipo de sistema computacional o Essas características são, contudo, independentes de produtos específicos: tais modelos são típicos da fase de projeto (ex.: arquitetura do software) o Físico o Características dependentes de um sistema computacional específico, isto é, uma linguagem e um compilador específico, um sistema gerenciador de bancos de dados específico, o hardware de um determinado fabricante, entre outras

21 Engenharia de requisitos o Análise de requisitos o Nas primeiras etapas do processo de desenvolvimento (levantamento de requisitos e análise), o engenheiro de software representa o sistema através de modelos conceituais o Nas etapas posteriores, as características lógicas e físicas são representadas em novos modelos o Paradigmas o Paradigmas de desenvolvimento estabelecem a forma de se ver o mundo e, portanto, definem as características básicas dos modelos a serem construídos o O paradigma orientado a objetos parte do pressuposto que o mundo é povoado por objetos, ou seja, a abstração básica para se representar as coisas do mundo são os objetos o O paradigma estruturado adota uma visão de desenvolvimento baseada em um modelo entrada-processamento-saída

22 Engenharia de requisitos o Processo de requisitos o Os processos de engenharia de requisitos variam de uma organização para outra, mas a maioria dos processos de Engenharia de Requisitos é composta das seguintes atividades: o Elicitação (levantamento) de requisitos o Análise de requisitos o Especificação de requisitos o Validação de requisitos

23 Engenharia de requisitos o Elicitação o Produção de um documento que possa ser revisado, avaliado e aprovado o Especificação de Requisitos de software o Estabelece as bases para o acordo entre clientes o Estabelece o que o software deve fazer e o que ele não deve o Permite avaliação rigorosa dos requisitos e evita retrabalho o Fornece base para estimar custo, prazo e risco e para elaboração dos planos de verificação e validação o Normalmente escrito em linguagem natural, mas pode utilizar outras notações que auxiliem na compreensão do software, como: modelos conceituais para ilustrar o contexto do sistema, cenários (ou telas), principais entidades do domínio e fluxogramas

24 Engenharia de requisitos o Processo de requisitos o Os processos de engenharia de requisitos variam de uma organização para outra, mas a maioria dos processos de Engenharia de Requisitos é composta das seguintes atividades: o Elicitação (levantamento) de requisitos o Análise de requisitos o Especificação de requisitos o Validação de requisitos

25 Engenharia de requisitos o Validação o O documento de requisitos deve ser validado pelos diferentes stakeholders (clientes e desenvolvedores) o Processo de examinar os documentos para ter certeza que eles definem se o software faz o que o usuário espera dele o Revisões de requisitos o A maneira mais comum é a inspeção ou revisão do documento o O grupo de revisão (com pelo menos um representante do cliente) busca por erros, contradições, falta de clareza e desvios de padrões o As revisões podem acontecer após o término de um dos documentos de requisitos ou em qualquer ponto do processo

26 Engenharia de requisitos o Validação o Prototipação o Construção de um protótipo para validação dos requisitos (também utilizado na elicitação) o Possibilita uma visão mais completa do funcionamento do SW o Teste de aceitação o Uma propriedade essencial do requisito é que deve ser possível validar se um produto finalizado é capaz de satisfazê-lo o Requisitos que não possam ser validados são desejos o É preciso planejar como testar os requisitos (projetando os testes de aceitação)

27 Engenharia de requisitos o Considerações sobre engenharia de requisitos o O processo de requisitos está em todo o ciclo de vida do software o Gerenciar a mudança e a manutenção dos requisitos são aspectos chave para o sucesso do processo de requisitos o Natureza iterativa do processo de requisitos o É impraticável implementar requisitos como um processo linear o O requisito sofre aperfeiçoamento continuado só ficando pronto quando o produto estiver terminado o Grande parte dos requisitos irá mudar por: erros de análise, mudanças no ambiente ou de negócio, etc. o Mudanças são inevitáveis e medidas devem ser tomadas para mitigar o seu impacto

28 Atividade 1.Definição da visão geral do software e o estado atual que motivou o desenvolvimento de um software. 1.Domínio 2.Visão geral e estado atual / Motivações 1.Principais funcionalidades 3.Usuários do sistema 1.Descrição de cenários (ou telas) 4.Requisitos funcionais 5.Requisitos não-funcionais

29 Técnicas e Projeto de Sistemas André Mesquita Rincon Engenharia de requisitos – Casos de uso Técnico Subsequente – Módulo III (22/03/2010)

30 Casos de uso o Visão geral de UML o Unified Modeling Language (Linguagem de Modelagem Unificada) o UML é uma linguagem para visualização, especificação, construção e documentação de artefatos de um software orientado a objeto o Visa facilitar a comunicação entre clientes e desenvolvedores

31 Casos de uso o Visão geral de UML o Diagrama de classes o Diagrama de objetos o Diagrama de casos de uso o Diagrama de seqüência o Diagrama de colaborações o Diagrama de gráficos de estados o Diagrama de atividades o Diagrama de componentes o Diagrama de implantação

32 Casos de uso o Introdução o É um documento narrativo que descreve a seqüência de eventos de um ator (um agente externo) que usa um sistema para completar um processo o Eles são histórias ou casos de utilização de um sistema

33 Casos de uso o Objetivo o Um diagrama de Caso de Uso descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário o O cliente deve ver no diagrama de Casos de Uso as principais funcionalidades de seu sistema

34 Casos de uso o Notação o O diagrama de Caso de Uso é representado por: o Atores, casos de uso e relacionamentos entre estes elementos o Estes relacionamentos podem ser: o associações entre atores e casos de uso o generalizações entre os atores o extends e includes entre os casos de uso o Casos de uso podem opcionalmente estar envolvidos por um retângulo que representa os limites do sistema

35 Casos de uso o Atores o Um ator é representado por um boneco e um rótulo com o nome do ator o Um ator é um usuário do sistema, que pode ser um usuário humano ou um outro sistema computacional

36 Casos de uso o Casos de uso o Um caso de uso é representado por uma elipse e um rótulo com o nome do caso de uso e define uma funcionalidade do sistema

37 Casos de uso o Relacionamento o Entre um ator de um caso de uso o Associação: define uma funcionalidade do sistema do ponto de vista do usuário o Entre atores o Generalização: os casos de uso de B são também casos de uso de A, mas A pode ter seus próprios casos de uso

38 Casos de uso o Relacionamento o Entre casos de uso o Include: um relacionamento include de um caso de uso A para um caso de uso B indica que B é essencial para o comportamento de A o Extend: um relacionamento extend de um caso de uso B para um caso de uso A indica que o caso de uso B pode ser acrescentado para descrever o comportamento de A (não é essencial). A extensão é inserida em um ponto de extensão do caso de uso A.

39 Casos de uso o Exemplo de diagrama de caso de uso

40 Atividade 1.Elabore o diagrama de caso de uso do seu sistema


Carregar ppt "Técnicas e Projeto de Sistemas André Mesquita Rincon Engenharia de requisitos Técnico Subsequente – Módulo."

Apresentações semelhantes


Anúncios Google