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

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

Curso de Requisitos Módulo 01: RUP Conceitos Essenciais de RUP.

Apresentações semelhantes


Apresentação em tema: "Curso de Requisitos Módulo 01: RUP Conceitos Essenciais de RUP."— Transcrição da apresentação:

1 Curso de Requisitos Módulo 01: RUP Conceitos Essenciais de RUP

2 Objetivos do Módulo Apresentar os Princípios-Chave do Desenvolvimento Orientado a Negócio Apresentar as facilidades de estrutura e navegação do RUP Apresentar os Guias e assistentes do RUP para o desenvolvimento Iterativo Introduzir o conteúdo do RUP e suas aplicações

3 O que é o RUP (Rational Unifield Process)? Três elementos-chave definem o RUP: –Um conjunto de princípios para um desenvolvimento de software com sucesso Estes princípios são a base do RUP –Um framework de conteúdo de método reutilizável e blocos de construção de processo Você pode criar suas próprias configurações de método, customizando o RUP para as necessidades de seu Projeto ou Empresa (veja o RMC ou EPF) –Uma Linguagem de Definição de Método e Processo Uma arquitetura de método unificada que provê uma linguagem para definir o conteúdo e os processo de seu Processo de Desenvolvimento customizado

4 Rational Method Composer (RMC) Biblioteca de Métodos com os seguintes plug-ins: –Rational Unified Process –Base Concepts –RUP Formal Resources –RUP Informal Resources –Business Modeling –Service-Oriented Architecture –RUP for J2EE –Rational Software Architect –Legacy Evolution –Rational Application Development Configurações já disponíveis para Uso: –RUP para Projetos Grandes –RUP para Projetos Pequenos

5 Quem deve usar o RUP? O RUP pode te ajudar a entregar e desenvolver software críticos para o sucesso de sua empresa O RUP foi pensado primariamente para dois grupos de usuário: –Participantes de uma equipe de desenvolvimento de software, inclusive os stakeholders –Engenheiros de Processo, principalmente de software e Gerentes de Software

6 Por que eu devo utilizar o RUP? RUP lhe fornece um processo de software baseado em padrões, customizável e configurável –Permite publicar um processo customizável e acessível para qualquer um –Permite customizar o processo para cada Projeto –Fornece uma visão filtrada para cada tipo de função (Visão para Analistas, Gerentes e etc) O RUP é formado por boas práticas de Engenharia de Software melhorado continuamente para refletir as mudanças da Indústria de Software

7 Por que devo utilizar o RUP (cont.) Para stakeholders: –Fornece um glossário de termos e uma enciclopédia de conhecimentos que lhe ajudam a comunicar suas necessidades à equipe de desenvolvimento Para integrantes da equipe –O RUP apresenta uma função central e comum de definição de processo que os membros podem compartilhar para melhorar a comunicação. Para gerentes e gerentes de projeto –Fornece um meio de comunicação efetivo com a equipe, ajudando da gerência, planejamento e controle Para Engenheiros de Processo –Fornece uma base de conhecimento, conteúdo e processos para formular o processo de desenvolvimento da Empresa ou do projeto.

8 Quando usar o RUP? O RUP pode ser usado desde o início até as fases de manutenção do projeto. O RUP pode ser customizado para suas necessidades, mas seguindo as considerações abaixo: Ciclo de Vida do Software (nº de iterações, tamanho das fases e do projeto) Objetivos de negócio do projeto, visão, escopo e risco Tamanho e complexidade do esforço de desenvolvimento

9 Discursão: Sintomas e Causas-Raiz Quais os sintomas de problemas no desenvolvimento dos softwares? Quais as causas-raiz de cada sintoma?

10 Sintomas dos Problemas de Desenvolvimento de Software Necessidades dos usuários não atendidas Confusão de Requisitos Módulos não integram Difícil de Manter Descoberta tardia de falhas Qualidade e iteratividade baixa Performance baixa Equipe não coordenada Problemas de build e release

11 Relação Problema-Causa Não atende necessid. Confusão Requisitos Modules dont fit Difícil Manter Descoberta tardia Qualidade baixa Performance baixa Time colide Build-e-release Requisitos insuficientes Comunicação ambígua Conflitos arquiteturais Alta complexidade Inconsistências escondidas Pouco teste Avaliação subjetiva Desenvolvimento Cascata Mudanças não controladas Automação insuficiente SintomaCausas RaizPrincípio-Chave Comunicação Ambígua Inconsistências escondidas Módulos não integram Adaptar o Processo Balancear requisições dos Stakeholders Demonstrar Valor Iterativamente Elevar Abstração Colaboração no time Focar qualidade continuamente

12 Princípios-Chave para o Desenvolvimento Orientado a Negócios F E D C B A Adapt The Process Balance Competing Stakeholder Priorities Collaborate Across Teams Demonstrate Value Iteratively Elevate Level Of Abstraction Focus Continuously On Quality

13 Principio: Adaptar o Processo Benefícios –Eficiência de Ciclo de Vida –Comunicação honesta e aberta dos riscos Padrão –Tamanho certo do processo para o processo –Adaptar a cerimônia do processo a fase do ciclo de vida e permitir a cerimônia as circunstâncias do projeto –Melhorar o processo continuamente –Balancear planos e estimativas ao nível de incertezas A É adaptar o processo ao tamanho do projeto. A quantidade de cerimônia, precisão e controle apresentada pelo projeto deve ser de acordo com o tamanho da equipe, se estão locais ou remotas, fase do projeto e quantidade de restrições do mesmo.

14 Tamanho certo do processo as necessidades do projeto Mais processo não é necessariamente melhor Para projetos menores com o time todos juntos localmente e tecnologia conhecida, o processo deve ser menor A medida que o projeto cresce, é necessário um processo mais disciplinado

15 Fatores que afetam o tamanho do processo Vários fatores afetam o tamanho do processo: –Tamanho do projeto –Distribuição geográfica da equipe –Complexidade tecnológica –Número de stakeholders –A fase do projeto

16 Princípio: Balancear Prioridades concorrentes do Stakeholder É importante balancear porque: –Frequentemente há conflitos de negócio e de necessidades –Questão de desenvolvimento customizado X pacotes prontos Benefícios –Alinhar a aplicação com o negócio e necessidades –Reduzir desenvolvimento customizado –Otimizar o valor do negócio Padrões –Definir, entender e priorizar o negócio e necessidades –Priorizar projetos e requisitos e relacionar necessidades com capacidades de sistema –Entender quais itens devemos considerar –Balancear o reuso de itens com necessidades do usuário B

17 Balancear necessidade de negócio e de usuário Gerenciar Requisitos efetivamente –Capturar processos de negócio –Priorizar projetos e capacidades do sistema para suportar necessidades de negócio Atualizar prioridades quando o entendimento do projeto cresce –Envolve o usuário para garantir o entendimento das necessidades, usando: Desenvolvimento orientado a casos de uso Design centrado no usuário Use soluções de pacote e itens existentes para entregar mais rápido e com custo menor

18 Entender quais itens absolver Entender quais itens estão disponíveis e balancear reuso de itens com necessidades Exemplos de itens: –Aplicações Legadas –Serviços –Componentes Reutilizáveis –Padrões

19 Princípio: Colaborar pelo time Benefícios –Produtividade do time –Melhor relacionamento entre necessidades do negócio e o desenvolvimento e operação de sistemas de software Padrões –Motivar pessoas para realizar o seu melhor –Criar times auto gerenciáveis –Encorajar colaboração pelas funções (analistas, gerentes, etc) –Fornecer ambiente colaborativos –Gerenciar o desenvolvimento de artefatos e tarefas para melhorar a colaboração –Integrar negócio, software e atividades do time C Prioriza comunicação otimizada no projeto. Alcançado com organização do time e ambientes colaborativos

20 Princípio: Demonstrar valor iterativamente Benefícios –Cedo de riscos cedo –Previsibilidade alta no projeto –Confiança junto aos stakeholders Padrões –Possibilita feedback ao entregar valor iterativamente –Adaptar seus planos usando o processo iterativo –Abraçar e gerenciar as mudanças –Atacar os maiores riscos técnicos, negociais e programáticos cedo. D O processo iterativo possibilita acomodar mudanças, obter feedback e reduzir riscos cedo

21 Habilitar feedback Entregando valor iterativamente Divida o projeto em iterações –Cada iteração realizará vários requisitos, design, implementação, teste da aplicação, produzindo um executável para o usuário Obter feedback dos stakeholders para: –Ver se estamos movendo na direção certa? –Stakeholders satisfeitos? –Precisamos alterar características já implementadas? –Que características adicionais precisam ser implementados para adicionar valor de negócio?

22 Adaptar seus Planos ao Processo Iterativo Desenvolvimento iterativo fornece um bom entendimento de: –Onde estamos? –Em qual velocidade o time está? –Precisamos fazer correções no curso para completar o projeto com sucesso Podemos usar esta informação para: –Atualizar o plano para o projeto –Desenvolver planos detalhados para a próxima iteração

23 Abraçe e Gerencie a Mudança As aplicações são muito complexas para que requisitos, design, implementação e teste funcionem na primeira vez Processos efetivos abraçam as mudanças O processo iterativo nos fornece a oportunidade de implementar mudanças incrementalmente

24 Ataque riscos cedo A necessidade de atacar riscos cedo não pode ser subestimado. Isto inclui: –Riscos técnicos –Riscos negociais –Riscos de programação Isto é feito avaliando riscos continuamente, atacando os maiores riscos nas primeiras iterações.

25 Perfil dos Riscos

26 Princípio: Elevar o nível de abstração Benefícios –Produtividade –Complexidade reduzida Padrões –Reuso de itens –Use ferramentas de alto-nível e linguagens para reduzir quantidade de documentação –Foco na arquitetura primeiro –Arquitetura para requisitos não funcionais: qualidade, flexibilidade e controle da complexidade E Reduz a complexidade e diminui a quantidade de documentação gerada. É alcançado com reuso, uso de modelagem visual e arquitetura estabilizada

27 Reuso de itens existentes Reduz complexidade de maior impacto na produtividade Trabalhando com alto nível de abstração reduz-se a complexidade e facilita-se a comunicação Reduzir complexidade reutilizando: –Componentes reutilizáveis –Sistemas legados –Processos existentes de negócio –Padrões –Software open-source

28 Princípio: Foco contínuo na Qualidade Benefícios –Alta qualidade –Alcance rápido do progresso e qualidade Padrões –Garantir a responsabilidade da equipe na qualidade do produto –Testar cedo e continuamente com integração das capacidades demonstráveis –Teste incremental e build contínuo F Enfatiza o alcance da qualidade. Um processo iterativo é adaptado para alcançar qualidade por que oferece várias métricas e oportunidades de correção

29 Visão Geral dos Conceitos do RUP

30 Uma abordagem iterativa Disciplinas agrupam atividades logicamente. Em uma iteração, você passa por todas as disciplinas.

31 Conteúdo do RUP - Fases O conteúdo do RUP é organizado em disciplinas Uma disciplina é um conjunto de tarefas relacionadas a uma área de interesse Disciplinas do RUP: –Requisitos –Modelagem de Negócio –Gerência de Configuração & Mudanças –Ambiente –Gerência de Projetos –Análise & Design –Implementação –Teste –Implantação

32 Disciplinas RUP tem disciplinas. Artefatos são desenvolvidos em cada disciplina através de um processo iterativo.

33 Disciplinas produzem e compartilham modelos Várias disciplinas produzem modelos… Análise & Design Requisitos Modelagem Negócio Implementa ção Implementado por Modelo de Implementação Modelo de Design Modelo de Caso de Uso Modelo de Negócio Business Analysis Model Realizado Por Automatizado por Realizado por Teste Verificado porValidado por BBB B …cada modelo é averiguado. Entrega Entrada para

34 Disciplinas de Requisito - Propósitos Estabelecer e manter um acordo com os usuários e outros stakeholders sobre o que o sistema deve fazer Fornece à equipe um melhor entendimento dos requisitos do sistema Define as fronteiras do sistema (escopo) Fornece a base para o planejamento das iterações Fornece uma base para estimar custo e tempo Define a interface visual do sistema baseado nas necessidades levantadas

35 Tipos de Requisito Características: escopo do projeto –Documentado no Documento de Visão Requisitos Funcionais: especifica interações com o usuário –Documentado nos Casos de Uso Requisitos Suplementares: especifica requisitos não funcionais (performance, segurança e etc), além de requisitos gerais do sistema, não específicos de um caso de uso –Especificação Suplementar

36 Conceitos de Modelagem de Casos de Uso Um ator representa uma pessoa ou outro sistema que se comunica com o sistema Um caso de uso define uma seqüência de ações que o sistema realiza para entregar algo de valor ao ator Actor Use Case

37 Ator Não é parte do sistema. Ele representa papéis que o ator desempenha Um ator pode iterativamente trocar informação com o sistema Um ator pode ser uma fonte de informação passiva Um ator pode entregar informação Um ator pode ser uma máquina, pessoa ou sistema

38 Um usuário pode agir como vários atores Charlie como Gerente Charlie Engenheiro Gerente Engenheiro Charlie

39 Caso de Uso Especifica um diálogo entre ator e sistema O caso de uso é iniciado por um ator que invoca uma funcionalidade do sistema Um caso de uso é completo e com um conjunto de fluxos entendível Todos juntos, os casos de uso representam as diversas formas de utilizar o sistema Use Case

40 Cenário – Um passo pelo caso de uso Um caso de uso pode ter várias instâncias Um cenário é descrito como uma instância de caso de uso: uma seqüência específica de ações que ilustra o comportamento do sistema Matrícula em Curso EstudanteFuncionário

41 Um diagrama UML Simples Professor Selecionar cursos para lecionar EstudanteSistema de Matrícula Registro em Curso Manter Estudante Manter Professor Digitador Sistema de Cobrança Fechar Matrícula

42 O que é um modelo de Caso de Uso Atores e suas descrições Diagramas de casos de uso e seus relacionamentos Para cada caso de uso: –Nome e descrição breve –Da especificação textual: Fluxo de eventos Pré e pós condições Requisitos especiais Outros diagramas (estado, seqüência, atividades, classes e etc)

43 Casos de Uso como base para planejamento Modelo Caso de Uso Especificações Suplementares Plano de Iteração Plano detalhado de Cada iteração Gerência de Projetos Restrições Durante elaboração, casos de uso são implementados para validar arquitetura.

44 Casos de Uso como base para modelagem verificação realizaçã o Modelo de Caso de Uso (requisitos) Modelo de Implementação (código fonte) Influência Modelo de Design (classes e objetos)

45 Disciplina de Modelagem Negócio Entender os problemas da organização-alvo e identificar melhorias Garantir o entendimento comum da organização-alvo Derivar requisitos de sistema para atender aos objetivos da organização-alvo Entender a estrutura e a dinâmica da organização em que o sistema está

46 O que os modelos de negócio mostram Clientes e vendedores Processos de negócio Estrutura da organização Papéis e responsabilidades Produtos Artefatos internos Eventos Modelo de Casos de Uso de Negócio Modelo de Análise de Negócio

47 Disciplina de Configuração e Mudanças Propósito: controlar mudanças e manter a integridade entre os artefatos do projeto

48 Gerência de Configuração As ferramentas de gerência de configuração suportam: –Realizar baseline de versões concorrentes –Identificação da configuração e gerência –Monitorar e apresentar as mudanças e status de configuração –Seleção de Versão –Métricas dos itens sob controle

49 Estrutura de Diretório do Projeto Local comum para os artefatos do projeto Estrutura lógica para organizar e versionar os artefatos

50 Gerência de Requisição de Mudanças Defeitos –Processo para gerenciar para todos a aquisição, conserto e reporte de erros nas atividades Requisições de Melhoria –Define um comitê de aprovação e controle das mudanças

51 Disciplina de Ambiente Processo Ferramentas Conhecimentos e competências para as atividades Problemas e possíveis melhorias Propósito: mantém o ambiente de hardware e software configurado para realizar as atividades do projeto, isto se refere a:

52 Artefatos Importantes de Ambiente Processo de Desenvolvimento (ex.: RUP) Caso de Desenvolvimento: descreve processos usados pelo projeto

53 Disciplina de Gerência de Projeto Modelo para gerenciar projetos Fornece guias para planejamento, alocação e monitoramento prático de projetos Gerencia os riscos Principais artefatos: –Plano de Projeto –Plano de Gerência de Risco –Caso de Negócio –Planos de Iteração

54 Disciplina de Análise e Design Propósito: transformar requisitos em um projeto do que deve ser feito Define uma arquitetura boa e flexível Adapta o projeto para um ambiente de implementação (linguagem, banco e etc) Principal artefato é o Modelo de Projeto

55 Realização do Caso de Uso em Análise e Design Modelo de Caso de Uso Realização de Caso de Uso (Modelo de Projeto) > Diagramas de Classe Diagramas de Sequência Diagramas de Colaboração Caso de Uso

56 Disciplina de Implementação Propósito: implementar classes e objetos definidos em análise e design em código- fonte, em executáveis A organização do código está dividida em componentes Testes unitários são desenvolvidos Cria executáveis Principal artefato: Código-fonte

57 Build É uma versão operacional do código-fonte que representa uma parte ou o sistema como um todo Fornece pontos de revisão Ajuda a descobrir problemas de integração do código mais cedo

58 Disciplina de Teste Propósitos –Procurar e documentar defeitos –Advertir sobre a qualidade do software –Validar se o sistema atende aos requisitos, necessidades e projeto desenhado –Usa ferramentas para automatizar o teste

59 Tipos de Teste Funcional Usabilidade Confiabilidade Performance Suportabilidade

60 Disciplina de Implantação Gerência as atividades de entrega do produto construído no ambiente do usuário Atividades: –Entrega do Produto –Teste e instalação nos ambientes alvo –Beta Teste –Material de suporte para o usuário final –Material de treinamento –Release dos produtos


Carregar ppt "Curso de Requisitos Módulo 01: RUP Conceitos Essenciais de RUP."

Apresentações semelhantes


Anúncios Google