Curso de Requisitos Módulo 01: RUP

Apresentação em tema: "Curso de Requisitos Módulo 01: 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
Sintoma Causas Raiz Princípio-Chave Módulos não integram Não atende necessid. Confusão Requisitos Modules don’t fit Difícil Manter Descoberta tardia Qualidade baixa Performance baixa Time colide Build-e-release Comunicação Ambígua Inconsistências escondidas 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 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
Adapt The Process Balance Competing Stakeholder Priorities Collaborate Across Teams Demonstrate Value Iteratively Elevate Level Of Abstraction Focus Continuously On Quality A B C D E F

13 Principio: Adaptar o Processo
É 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. A 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

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

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
Prioriza comunicação otimizada no projeto. Alcançado com organização do time e ambientes colaborativos 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

20 Princípio: Demonstrar valor iterativamente
O processo iterativo possibilita acomodar mudanças, obter feedback e reduzir riscos cedo D 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.

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
Reduz a complexidade e diminui a quantidade de documentação gerada. É alcançado com reuso, uso de modelagem visual e arquitetura estabilizada 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

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
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 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

29 Visão Geral dos Conceitos do RUP

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

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… Modelagem Negócio Requisitos Análise & Implementação Design Entrada para Entrega Realizado por Implementado por Realizado Por Modelo de Negócio Modelo de Caso de Uso B Automatizado por Business Analysis Model Modelo de Design Modelo de Implementação Verificado por Validado por …cada modelo é averiguado. Teste

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 Use Case Actor

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 Gerente Charlie Engenheiro Charlie Engenheiro

39 Caso de Uso Especifica um diálogo entre ator e sistema
Use Case 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

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 Estudante Matrícula em Curso Funcionário

41 Um diagrama UML Simples
Estudante Registro em Curso Sistema de Matrícula Professor Selecionar cursos para lecionar Manter Professor Digitador Manter Estudante 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
Restrições Plano de Iteração Gerência de Projetos Modelo Caso de Uso Especificações Suplementares Plano detalhado de Cada iteração Durante elaboração, casos de uso são implementados para validar arquitetura.

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

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
Propósito: mantém o ambiente de hardware e software configurado para realizar as atividades do projeto, isto se refere a: Processo Ferramentas Conhecimentos e competências para as atividades Problemas e possíveis melhorias

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
<<realizes>> Modelo de Caso de Uso Realização de Caso de Uso (Modelo de Projeto) Caso de Uso Diagramas de Sequência Diagramas de Colaboração Diagramas de Classe

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