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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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.

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?

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

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

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.

Perfil dos Riscos

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

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

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

Visão Geral dos Conceitos do RUP

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

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

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

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

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

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

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

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

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

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

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

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

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)

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.

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)

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á

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

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

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

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

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

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

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

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

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

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

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

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

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

Tipos de Teste Funcional Usabilidade Confiabilidade Performance Suportabilidade

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