Disciplina - Requisitos. Grupo Yuni Luiz Eduardo Káthia

Transcrição

1 Disciplina - Requisitos Grupo Yuni Luiz Eduardo Káthia

2 RUP(Rational Unified Process) 1. Introdução. 2. Introdução a disciplinas no RUP. 3. Requisitos. 4. Gerenciamento de Requisitos. 5. Relação com outras Disciplinas 6. Conclusão.

3 Introdução O RUP, abreviação de Rational Unified Process (ou Processo Unificado da Rational), é um processo proprietário de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM tornando-se uma brand (marca) na área de Software, fornecendo técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade.

4

5 Define-se o escopo do projeto Avalia-se a tecnologia Relaciona-se os riscos principais Detecta-se áreas mais críticas a serem tratadas Verifica-se a viabilidade do projeto

6 Especifica-se os requisitos em detalhes Identifica-se e avalia-se a arquitetura do software

7 Introdução a disciplinas no RUP É uma coleção de atividades relacionadas que fazem parte de um contexto comum em um projeto. As disciplinas proporcionam um melhor entendimento do projeto sob o ponto de vista tradicional de um processo cascata. A separação das atividades em disciplinas torna a compreensão das atividades mais fácil, porém dificulta mais o planejamento das atividades. O RUP possui nove disciplinas, divididas em disciplinas do processo e de suporte. As disciplinas de processo são: modelagem de negócios, requisitos, análise e projeto, implementação, teste e distribuição. As de suporte são: configuração e gerenciamento de mudanças, gerenciamento de projeto, e ambiente.

8 Requisitos A finalidade da disciplina Requisitos é: Estabelecer e manter concordância com os clientes e outros envolvidos sobre o que o sistema deve fazer. Oferecer aos desenvolvedores do sistema uma compreensão melhor dos requisitos do sistema. Definir as fronteiras do sistema (ou delimitar o sistema). Fornecer uma base para planejar o conteúdo técnico das iterações. Fornecer uma base para estimar o custo e o tempo de desenvolvimento do sistema. Definir uma interface de usuário para o sistema, focando nas necessidades e metas dos usuários.

9 Requisitos Para atingir essas metas, é importante, antes de tudo, compreender a definição e o escopo do problema que tentamos resolver com este sistema.

10 Gerenciamento de Requisitos O gerenciamento de requisitos no RUP estão concentrados em encontrar as necessidades do usuário final pela identificação e especificação do que ele necessita e identificando aquilo que deve ser mudado. Isto traz como benefícios: A correção dos requerimentos gera a correção do produto, as necessidades dos usuários são encontradas. As características necessárias irão ser incluídas, reduzindo o custo de desenvolvimentos posteriores.

11 Gerenciamento de Requisitos RUP sugere que o gerenciamento requisitos tem que seguir estas atividades: Analise do problema: é concordar com o problema e criar medições que irão provar seu valor para a organização. Entender as necessidades de seus stakeholders (interveniente): é compartilhar o problema e valores com os stakeholders-chave e levantar quais as necessidades que estão envolvidas na elaboração da ideia. Definir o problema: é a definição das características das necessidades e esquematizar os casos de uso, atividades que irão facilmente mostrar os requisitos de alto-nível e esboçar o modelo de uso do sistema.

12 Gerenciamento de Requisitos Gerenciar o escopo do sistema: trata das modificações de escopo que irão ser comunicadas baseadas nos resultados do andamento e selecionadas na ordem na qual os fluxogramas de casos de uso são atacados. Refinar as definições do sistema: trata do detalhamento de caso de uso com os stakeholders de forma a criar uma especificação de requisitos de software que pode servir como um contrato entre o seu grupo e o do cliente e poderá guiar as atividades de teste e projeto. Gerenciamento das mudanças de requisitos: trata de como identificar as chegadas das mudanças de requisito num projeto que já começou.

13 Gerenciamento de Requisitos Gerenciar o escopo do sistema: trata das modificações de escopo que irão ser comunicadas baseadas nos resultados do andamento e selecionadas na ordem na qual os fluxogramas de casos de uso são atacados. Refinar as definições do sistema: trata do detalhamento de caso de uso com os stakeholders de forma a criar uma especificação de requisitos de software que pode servir como um contrato entre o seu grupo e o do cliente e poderá guiar as atividades de teste e projeto. Gerenciamento das mudanças de requisitos: trata de como identificar as chegadas das mudanças de requisito num projeto que já começou.

14 Relação com outras Disciplinas A disciplina Requisitos está relacionada a outras disciplinas do processo. A disciplina Modelagem de Negócios fornece as Regras de Negócios, um Modelo de Casos de Uso de Negócios e um Modelo de Objeto de Negócio, incluindo um Modelo de Domínio e um contexto organizacional para o sistema. A disciplina Análise e Design obtém suas informações primárias (o modelo de casos de uso e o Glossário) dos Requisitos. Falhas no modelo de casos de uso podem ser descobertas durante a atividade de análise e de design; solicitações de mudança são, então, geradas e aplicadas ao modelo de casos de uso.

15 Relação com outras Disciplinas A disciplina Teste valida o sistema com base (entre outras coisas) no Modelo de Casos de Uso. Os Casos de Uso e as Especificações Suplementares fornecem informações sobre os requisitos usados na definição da missão de avaliação e nas atividades subsequentes de teste e avaliação. A disciplina Gerenciamento de Configuração e Mudança fornece o mecanismo para controle de mudanças dos requisitos. O mecanismo para proposta de uma mudança consiste em enviar uma Solicitação de Mudança, que será analisada pelo Comitê de Controle de Mudança. A disciplina Gerenciamento de Projeto planeja o projeto e cada iteração (descritas em um Plano de Iteração). O modelo de casos de uso e o Plano de Gerenciamento de Requisitos são informações importantes fornecidas às atividades de planejamento de iterações.

16 Relação com outras Disciplinas A disciplina Ambiente desenvolve e mantém os artefatos de suporte usados no gerenciamento de requisitos e na modelagem de caso de uso, como o Guia de Modelagem de Caso de Uso e o Guia de Interface do Usuário.

17 Conclusão O RUP (Rational Unified Process) é uma metodologia que provê a qualidade de software, aumento de produtividade e melhorias na manutenção além de ajudar no controle sobre todas as fases de desenvolvimento do software.

18 Bibliografia FERNANDES, J.: Visão Geral do RUP Rational Unified Process. UFRN, junho de Disponível em: < 20slides.pdf>. Acesso em: 22 fev BORTOLI, J.:RUP - Rational Unified Process. Disponível em: < Acesso em: 22 fev SANCHES, ROSELY. Material Didático: Engenharia de Software. ICMC-USP, PRESSMAN, ROGER S. Engenharia de Software. 5ª edição. Rio de Janeiro: McGraw-Hill, SOMERVILLE, IAN. Engenharia de Software. 6ª edição. São Paulo: Addison Wesley, 2003.