Upload
internet
View
118
Download
3
Embed Size (px)
Citation preview
Curso de RequisitosMó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
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
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
Sintoma Causas Raiz Princí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
Princípios-Chave para o Desenvolvimento Orientado a Negócios
F
E
D
C
B
A Adapt The ProcessBalance Competing Stakeholder PrioritiesCollaborate Across TeamsDemonstrate Value IterativelyElevate Level Of AbstractionFocus Continuously On Quality
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.
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
B
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
• 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
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.
DO processo iterativo possibilita acomodar mudanças, obter feedback e reduzir riscos 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
• 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
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
• 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
Visão Geral dos Conceitos do RUP
Uma abordagem iterativa
Disciplinas agrupam
atividades logicamente.
Em uma iteração, você passa por todas as disciplinas.
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…
Análise & Design
RequisitosModelagemNegócio
Implementação
Implementado
por
Modelo deImplementação
Modelo de Design
Modelo deCaso de Uso
Modelo deNegócio
Business Analysis Model
RealizadoPor
Automatizadopor
Realizado por
Teste
Verificado por Validado por
BBB
B
…cada modelo é averiguado.
Entrega
Entrada para
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
Actor Use Case
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
Charlie Engenheiro
Gerente
EngenheiroCharlie
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
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 emCurso
Estudante Funcionário
Um diagrama UML Simples
Professor
Selecionar cursos para lecionar
Estudante
Sistema de Matrícula
Registro em Curso
Manter Estudante
Manter Professor
Digitador
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
Modelo Caso de Uso
EspecificaçõesSuplementares
Plano de Iteração
Plano detalhado deCada iteração
Gerência de
Projetos
Restrições
Durante elaboração, casos de uso são implementados para validar arquitetura.
Casos de Uso como base para modelagem
verificaçãorealização
Modelo de Caso de Uso(requisitos)
Modelo de Implementação(código fonte)
Influência
Modelo de Design(classes e objetos)
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çasPropó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
• 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:
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
Modelo de Caso de Uso Realização de Caso de Uso(Modelo de Projeto)
<<realizes>>
Diagramas de Classe
Diagramas de Sequência Diagramas de ColaboraçãoCaso de Uso
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