Técnicas e Projeto de Sistemas

Apresentação em tema: "Técnicas e Projeto de Sistemas"— Transcrição da apresentação:

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

2 Engenharia de requisitos
Introduçã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
Introduçã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 Área do conhecimento do SWEBOK responsável pela elicitação, análise, especificação e validação dos requisitos O SWEBOK a denomina apenas Requisitos

4 Engenharia de requisitos
Definição Requisitos expressam necessidades e limitações sobre um produto que soluciona um problema do mundo real 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 São parâmetros do produto que será desenvolvido (i.e.: requisitos sobre o que o software deve fazer) Requisitos devem ser definidos com clareza e de forma quantificável

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

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

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

8 Processo de requisitos
Engenharia de requisitos Processo de requisitos 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: Elicitação (levantamento) de requisitos Análise de requisitos Especificação de requisitos Validação de requisitos

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

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

11 Elicitação (levantamento) – técnicas
Engenharia de requisitos Elicitação (levantamento) – técnicas Algumas dificuldades geralmente são encontradas: Dificuldades dos usuários em descrever suas funções Falta de vontade em cooperar 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 Sistema atual não referencia apenas softwares atuais

12 Elicitação (levantamento) – técnicas auxiliares
Engenharia de requisitos Elicitação (levantamento) – técnicas auxiliares O&M Elaboração de funcionogramas e fluxogramas do ambiente de operaçã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 Exemplo 1 – Funcionograma Exemplo 2 – Fluxograma sem software Exemplo 3 – Fluxograma com software

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

14 Processo de requisitos
Engenharia de requisitos Processo de requisitos 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: Elicitação (levantamento) de requisitos Análise de requisitos Especificação de requisitos Validação de requisitos

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

16 Análise de requisitos Engenharia de requisitos
Estabelecer um conjunto de requisitos consistentes e sem ambigüidades, que possa ser usado como base para o desenvolvimento do software Deve-se classificar os requisitos em: Funcionais e não funcionais Para esta atividade, alguns tipos de modelos podem ser construídos 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
Análise de requisitos São fundamentais no desenvolvimento de sistemas e são construídos para: Auxiliar no estudo do comportamento do sistema Facilitar a comunicação entre os componentes da equipe e clientes e usuários Facilitar a discussão de correções e modificações com o usuário Formar a documentação do sistema

18 Engenharia de requisitos
Análise de requisitos Como foi dito, os modelos possuem níveis de abstraçã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 No caso do desenvolvimento de sistemas, geralmente, são considerados três níveis: Conceitual Lógico Físico

19 Análise de requisitos – níveis de abstração
Engenharia de requisitos Análise de requisitos – níveis de abstração Conceitual Considera características do sistema independentes do ambiente computacional no qual o sistema será implementado Essas características são dependentes unicamente das necessidades do usuário Modelos conceituais são construídos na atividade de análise de requisitos 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 A utilização de uma notação “aceitável” pela maioria pode trazer benefícios (UML)

20 Análise de requisitos – níveis de abstração
Engenharia de requisitos Análise de requisitos – níveis de abstração Lógico Características dependentes de um determinado tipo de sistema computacional 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) Físico 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 Análise de requisitos Engenharia de requisitos
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 Nas etapas posteriores, as características lógicas e físicas são representadas em novos modelos Paradigmas 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 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 paradigma estruturado adota uma visão de desenvolvimento baseada em um modelo entrada-processamento-saída

22 Processo de requisitos
Engenharia de requisitos Processo de requisitos 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: Elicitação (levantamento) de requisitos Análise de requisitos Especificação de requisitos Validação de requisitos

23 Elicitação Engenharia de requisitos
Produção de um documento que possa ser revisado, avaliado e aprovado Especificação de Requisitos de software Estabelece as bases para o acordo entre clientes Estabelece o que o software deve fazer e o que ele não deve Permite avaliação rigorosa dos requisitos e evita retrabalho Fornece base para estimar custo, prazo e risco e para elaboração dos planos de verificação e validaçã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 Processo de requisitos
Engenharia de requisitos Processo de requisitos 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: Elicitação (levantamento) de requisitos Análise de requisitos Especificação de requisitos Validação de requisitos

25 Validação Engenharia de requisitos
O documento de requisitos deve ser validado pelos diferentes stakeholders (clientes e desenvolvedores) Processo de examinar os documentos para ter certeza que eles definem se o software faz o que o usuário espera dele Revisões de requisitos A maneira mais comum é a inspeção ou revisão do documento 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 As revisões podem acontecer após o término de um dos documentos de requisitos ou em qualquer ponto do processo

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

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

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

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

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

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

32 Casos de uso Introduçã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 Eles são histórias ou casos de utilização de um sistema

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

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

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

36 Casos de uso Casos de uso 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 Relacionamento Entre um ator de um caso de uso Entre atores
Casos de uso Relacionamento Entre um ator de um caso de uso Associação: define uma funcionalidade do sistema do ponto de vista do usuário Entre atores 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 Relacionamento Entre casos de uso Casos de uso
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 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 Exemplo de diagrama de caso de uso
Casos de uso Exemplo de diagrama de caso de uso

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