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