SlideShare uma empresa Scribd logo
Carlos Henrique M. da Silva
carloshenrique.85@globo.com
1. Histórico e Conceitos
2. Melhores práticas
3. Fases
4. Disciplinas
O RUP, Processo Unificado Racional é um processo proprietário de
Engenharia de software criado pela Rational Software Corporation,
adquirida pela IBM, ganhando um novo nome IRUP e tornando-se
uma brand na área de Software, fornecendo técnicas a serem
seguidas pelos membros da equipe de desenvolvimento de software
com o objetivo de aumentar a sua produtividade no processo de
desenvolvimento.
O RUP usa a abordagem da orientação a objetos em sua concepção e
é projetado e documentado utilizando a notação UML (Unified
Modeling Language) para ilustrar os processos em ação. Utiliza
técnicas e práticas aprovadas comercialmente.
O RUP é, por si só, um produto de software. É modular e
automatizado, e toda a sua metodologia é apoiada por diversas
ferramentas de desenvolvimento integradas e vendidas pela IBM
através de seus "Rational Suites".
Métodos concorrentes no campo da engenharia de software incluem
o "Cleanroom" (considerado pesado) e os Métodos Ágeis (leves) como
a Programação Extrema (XP), Scrum, FDD (Desenvolvimento Guiado
por Funcionalidades) entre outros.
Objetivo é assegurar a produção de software de alta qualidade
dentro de prazos e orçamentos previsíveis (Kruchten 2003, pág. 14)
O RUP define perfeitamente quem é responsável pelo que, como as
coisas deverão ser feitas e quando devem ser realizadas,
descrevendo todas as metas de desenvolvimento especificamente
para que sejam alcançadas.
Oferece uma abordagem organizada em disciplinas para atribuir
tarefas e responsabilidades dentro de uma organização de
desenvolvimento.
Melhores Práticas
 Desenvolver software iterativamente
 Gestão de requisitos
 Uso de arquitetura baseada em componentes
 Uso de software de modelos visuais
 Verificação da qualidade do software
 Gestão e Controle de Mudanças do Software
Desenvolver Software Iterativamente
Desenvolver iterativamente significa desenvolver em ciclos. Cada
ciclo é contém um objetivo que deve ser alcançado (lançamento de
um pré release ou beta, correção de um bug, etc.)
Esta prática acaba dando ao RUP uma série de vantagens, como:
 Possibilidade de identificar/modificar requerimentos com mais
facilidade;
 Integração progressiva (quase continua) de elementos ao
software, ocasionando uma melhora no descobrimento e
endereçamento de riscos;
 Desenvolvimento iterativo provê aos gerentes maneiras de
fazer mudanças táticas aos produtos; etc.
Gestão de Requisitos
O gerenciamento de recursos acarreta um melhor controle sobre
projetos complexos, além de maior qualidade e redução de custos.
O RUP é uma metodologia dirigida-a-casos-de-uso (use-
drivencase), de modo que é possível utilizar os mesmos casos de
uso definidos no sistema como base para o resto do processo.
Os casos de uso (em inglês Use Cases) e os cenários são exemplos
de artefatos dependentes do processo, que têm sido considerados
muito mais eficazes na captura de requisitos funcionais.
Arquitetura Baseada em
Componentes
Um componente normalmente se relaciona com um objeto na
programação orientada a objetos.
O RUP oferece uma forma sistemática para construir este tipo de
sistema, focando-se em produzir uma arquitetura executável nas
fases iniciais do projeto, ou seja, antes de comprometer recursos em
larga escala.
Estes componentes são normalmente incluídos em infraestruturas
existentes como o CORBA e o COM (Modelo de Componentes de
Objetos).
Uso de Software de Modelos Visuais
A modelagem visual permite melhor entender não só a concepção e a
complexidade do sistema, mas também “dimensionar” (no sentido de
qual a forma do sistema), além de facilitar a identificação e solução
de problemas.
Verificação da qualidade do software
Não assegurar a qualidade do software é a falha mais comum em
todos os projetos de sistemas computacionais. Normalmente pensa-
se em qualidade de software após o término dos projetos, ou a
qualidade é responsabilidade de uma equipe diferente da equipe de
desenvolvimento.
O RUP não toma a qualidade como responsabilidade de apenas uma
pessoa ou grupo, mas como uma responsabilidade de todos os
integrantes do projeto.
A qualidade é focada especialmente em duas áreas:
 Qualidade de produto: Sendo desenvolvido (software ou sistema) e
todos as partes envolvidas (componentes, subsistemas, arquitetura).
 Qualidade de processo: Dentro do projeto de desenvolvimento.
Gestão e Controle de Mudanças do
Software
Em todos os projetos de software a existência de mudanças é
inevitável. O RUP define métodos para controlar e monitorar
mudanças. Como uma pequena mudança pode afetar aplicações de
formas inteiramente imprevisíveis, o controle de mudanças é
essencial para o sucesso de um projeto.
O RUP também define áreas de trabalho seguras, garantindo a um
programador que as mudanças efetuadas noutro sistema não
afetarão o seu sistema.
Fases de Desenvolvimento
Até agora estas linhas de guia são gerais, a serem aderidas ao
percorrer do ciclo de vida de um projeto. As fases indicam a ênfase
que é dada no projeto em um dado instante. Para capturar a
dimensão do tempo de um projeto, o RUP divide o projeto em
quatro fases diferentes:
1. Concepção: ênfase no escopo do sistema;
2. Elaboração: ênfase na arquitetura;
3. Construção: ênfase no desenvolvimento;
4. Transição: ênfase na implantação.
Fases de Desenvolvimento
O RUP também se baseia nos 4 Ps:
1. Pessoas
2. Projeto
3. Produto
4. Processo
As fases são compostas de iterações. As iterações são janelas de
tempo; as iterações possuem prazo definido enquanto as fases são
objetivas.
Todas as fases geram artefatos. Estes serão utilizados nas próximas
fases e documentam o projeto, além de
permitir melhor acompanhamento.
Fase de Concepção
Esta fase do RUP abrange as tarefas de comunicação com o cliente e
planejamento.
É feito um plano de projeto avaliando os possíveis riscos, as
estimativas de custo e prazos, estabelecendo as prioridades,
levantamento dos requisitos do sistema e preliminarmente analisá-
lo. Assim, haverá uma anuência das partes interessadas na definição
do escopo do projeto, onde são examinados os objetivos para se
decidir sobre a continuidade do desenvolvimento.
Fase de Elaboração
Abrange a Modelagem do modelo genérico do processo.
O objetivo desta fase é analisar de forma mais detalhada a análise do
domínio do problema, revisando os riscos que o projeto pode sofrer
e a arquitetura do projeto começa a ter sua forma básica.
Indagações como “O plano do projeto é confiável?”, “Os custos são
admissíveis?” são esclarecidas nesta etapa.
Fase de Construção
Desenvolve ou Adquire os componentes de Software.
O principal objetivo desta fase é a construção do sistema de
software, com foco no desenvolvimento de componentes e outros
recursos do sistema.
É na fase de Construção que a maior parte de codificação ocorre.
Fase de Transição
Abrange a entrega do software ao usuário e a fase de testes.
O objetivo desta fase é disponibilizar o sistema, tornando-o
disponível e compreendido pelo usuário final.
As atividades desta fase incluem o treinamento dos usuários finais e
também a realização de testes da versão beta do sistema visando
garantir que o mesmo possua o nível adequado de qualidade.
Disciplinas
As disciplinas descrevem o aspecto estático do processo, como ele é
descrito em termos de componentes, disciplinas, atividades, fluxos
de trabalho, artefatos e papéis do processo. São divididas em:
 Seis Disciplinas de Engenharia
 Modelagem de Negócios
 Requisitos
 Análise e Projeto ("Design")
 Implementação
 Teste
 Implantação
 Três Disciplinas de Apoio/Suporte
 Ambiente
 Configuração e Gerência de Mudança
 Gerência de Projeto
Engenharia - Disciplina de Modelagem de Negócios
Modelagem de negócios, explica como descrever uma visão da
organização na qual o sistema será implantado e como usar esta
visão como uma base para descrever o processo, papéis e
responsabilidades.
O objetivo de modelagem de negócios é, primeiramente, estabelecer
uma melhor compreensão e canal de comunicação entre engenharia
de negócios e engenharia de software. Compreender o negócio
significa que os engenheiros de software devem compreender a
estrutura e a dinâmica da empresa alvo (o cliente), os atuais
problemas na organização e possíveis melhorias.
Engenharia - Disciplina de Requisitos
Esta disciplina explica como levantar pedidos das partes interessadas
("stakeholders") e transformá-los em um conjunto de requisitos que
os produtos funcionam no âmbito do sistema a ser construído e
fornecem requisitos detalhados para o que deve fazer o sistema.
Engenharia - Disciplina de Análise e Projeto (“Design”)
O objetivo da análise e projeto é mostrar como o sistema vai ser
realizado. O objetivo é construir um sistema que:
 Execute as tarefas e funções especificadas nas descrições;
 Cumpra todas as suas necessidades;
 Seja fácil de manter quando ocorrerem mudanças de requisitos
funcionais.
Engenharia - Disciplina de Implementação
Os efeitos da implementação são:
 Para definir a organização do código, em termos de subsistemas
de implementação organizadas em camadas
 Para implementar classes e objetos em termos de componentes
(arquivos-fonte, binários, executáveis e outros)
 Para testar os componentes desenvolvidos como unidades
 Integrar os resultados produzidos por implementadores
individuais (ou equipes), em um sistema executável
Engenharia - Disciplina de Teste
As finalidades da disciplina de teste são:
 Verificar a interação entre objetos
 Verificar a integração adequada dos componentes do software
 Verificar se todos os requisitos foram corretamente
implementados
 Identificar e garantir que os defeitos são abordados antes da
implantação do software
 Garantir que todos os defeitos são corrigidos, reanalisados e
fechados
O RUP propõe uma abordagem iterativa, o que significa que deve-se
testar todo o projeto. Os testes são realizados ao longo de 4
dimensões da qualidade: Confiabilidade, Funcionalidade,
Desempenho da aplicação, e o Desempenho do sistema.
Engenharia - Disciplina de Implantação
O objetivo da implantação é o de produzir com sucesso lançamentos
de produtos e entregar o software para seus usuários finais.
Ele cobre uma vasta gama de atividades, incluindo a produção de
releases externos do software, a embalagem do software e
aplicativos de negócios, distribuição do software, instalação do
software e prestação de ajuda e assistência aos usuários.
Embora as atividades de implantação estejam principalmente
centradas em torno da fase de transição, muitas das atividades
devem ser incluídas nas fases anteriores para se preparar para a
implantação, no final da fase de construção.
Os processos ("workflows") de "Implantação e Ambiente" do RUP
contêm menos detalhes do que outros workflows.
Apoio/Suporte - Disciplina de Ambiente
O ambiente enfoca as atividades necessárias para configurar o
processo para um projeto.
Ele descreve as atividades necessárias para desenvolver as diretrizes
de apoio a um projeto.
A proposta das atividades de ambiente é prover à organização de
desenvolvimento de software os processos e as ferramentas que
darão suporte à equipe de desenvolvimento.
Se os usuários do RUP não entendem que o RUP é um framework de
processo, eles podem percebê-lo como um processo pesado e caro.
Apoio/Suporte - Disciplina de Configuração e
Gerência de Mudança
A disciplina de Gestão de Mudança em negócios com RUP abrange
três gerenciamentos específicos: de configuração, de solicitações de
mudança, e de status e medição.
A Rational também tem um produto para manter as solicitações de
mudança chamado ClearQuest.
Apoio/Suporte - Disciplina de Gerência de Projeto
Esta disciplina concentra-se principalmente sobre os aspectos
importantes de um processo de desenvolvimento iterativo:
Gestão de riscos; Planejamento de um projeto iterativo através do
ciclo de vida e para uma iteração particular; E o processo de
acompanhamento de um projeto iterativo, métricas. No entanto, esta
disciplina do RUP não tenta cobrir todos os aspectos do
gerenciamento de projetos. Por exemplo, não abrange questões
como:
 Gestão de Pessoas: contratação, treinamento, etc.
 Orçamento Geral: definição, alocação, etc.
 Gestão de Contratos: com fornecedores, clientes, etc.
Embora o RUP não seja um processo adequado a todos os tipos de
desenvolvimento de software, ele representa uma nova geração de
processos genéricos. A mais importante inovação é a separação de
fases e workflows, e o reconhecimento de que a implantação de
software no ambiente do usuário é parte do processo. As fases são
dinâmicas e tem objetivos. Os workflows são estáticos e constituem
atividades técnicas que não estão associadas a uma única fase, mas
podem ser utilizados ao longo do desenvolvimento para atingir os
objetivos de cada fase (Sommerville 2007, pág. 56).
Conclusão
Rational Unified Process
DISCIPLINAS
Vamos agorar conhecer um pouco mais sobre as
6 disciplinas de engenharia do RUP:
Modelagem de Negócios
Requisitos
Análise e Projeto ("Design")
Implementação
Teste
Implantação
DISCIPLINA DE
MODELAGEM DE
NEGÓCIOS
Modelagem de Negócios
É uma das 9 disciplinas do RUP e a primeira das 6 consideradas “core
disciplines”. Dentro do ciclo de desenvolvimento de software
podemos dizer que essa é sem dúvida a disciplina menos praticada.
RUP não define esta como uma disciplina obrigatória, mas recomenda
fortemente que ela seja executada especialmente para empresas que
estão iniciando um novo negócio e não possuam uma clara
modelagem do negócio.
Modelagem de Negócios
Finalidades:
 Entender os problemas da organização identificando as
possíveis melhorias;
 Avaliar o impacto de mudanças na organização;
 Assegurar que os clientes, usuários, desenvolvedores e outros
parceiros tenham uma compreensão comum da organização;
 Gerar conteúdo para a fase de requisitos do sistema que
suportará a organização e seus processos;
 Entender como o software se ajustará à organização.
Modelagem de Negócios
Papéis e Artefatos
A importância da definição de papéisnão é somente para melhorar
divisão do trabalho, mas principalmente para que hajana equipe
responsabilidades definidas para cada atividade realizada, fazendo,
assim,com que os membros tenham que cumprir direitinho as suas
tarefas e que respondam por elas.
 Gerente de Projeto
 Analista de Processos de Negócio (Dentro da disciplina de
Modelagem de Negócios, esse é o papel mais importante)
 Designer de Negócio
Gerente de Projeto
Talvez seja um dos únicos papéis que estarão presentes em todos os
projetos e em todas as suas fases, independente do tamanho,
natureza ou metodologia de desenvolvimento adotada.
Inicialmente, o gerente de projeto era o indivíduo que identificava as
tarefas necessárias, as delegava aos membros da equipe e ficava
pressionando cada um para cumprir os prazos.
Hoje, essa realidade mudou. O gerente de projeto é um indivíduo
extremamente participativo: realiza parcerias com os membros da
equipe, estimula e valoriza as soluções encontradas e conduz o
andamento do projeto, protegendo a equipe de distrações e
organizando cronogramas, defende os interesses do time e realiza a
comunicação com o cliente.
Modelagem de Negócios
Analista de Processos de Negócio
Modelagem de Negócios
Designer de Negócios
Modelagem de Negócios
Modelagem de Negócios
Relação com Outras Disciplinas
A disciplina Requisitos utiliza modelos de negócios como
um importante subsídio para entender os requisitos do
sistema.
A disciplina Análise e Design utiliza entidades de
negócios como subsídio para identificar classes de
entidade no modelo de design.
A disciplina Ambiente desenvolve e mantém artefatos de
suporte, como o Guia de Modelagem de Negócios.
DISCIPLINA DE
REQUISITOS
O objetivo da disciplina Requisitos é descrever o que o sistema deve
fazer e permite que desenvolvedores e clientes concordem com essa
descrição. Para conseguir isso, obter, organizar e funcionalidade
documento desejado e restrições; acompanhar e documentar
compromissos e decisões.
Uma visão do documento é criada, e necessidades das partes
interessadas são extraídas. Atores e casos de uso são identificados.
REQUISITOS
O QUE É UM REQUISITO?
 Condição ou capacidade que um sistema deve desempenhar
 Qualidade de software
 Funcionalidade: requisitos funcionais
 Requisitos não funcionais
 Usabilidade
 Confiabilidade
 Performance
 Suportabilidade – manutenabilidade
TIPOS DE REQUISITOS
 Serviços (features)
 Expressões de comportamento do sistema em alto nível (o quê)
 Solicitações dos stakeholders
 Requisitos do software
 Requisitos de casos de usos
Processo de levantamento de requisitos
proposto pelo RUP (José Martins, 2004)
REQUISITOS
ATIVIDADES
ARTEFATOS
ENGENHARIA DE REQUISITOS
É fundamental para o desenvolvimento de um software a
compreensão dos requisitos. Se a análise e a especificação das
funções não forem definidas adequadamente o software não atenderá
as necessidades do usuário.
A Engenharia de Requisito tem como objetivo a elaboração de um
documento com as características do sistema. Este documento serve
de referência para todas as pessoas envolvidas no processo de
desenvolvimento inclusive os clientes.
Com a chegada da engenharia de requisitos, se fez necessário à
elaboração de um processo visando organizar as atividades. É o que
analisaremos nos tópicos abaixo.
Processo de Engenharia de Requisitos
O processo de Engenharia de Requisitos é um conjunto de atividades
a serem seguidas para desenvolver um documento de requisitos.
Sommerville sugere um modelo de atividades que pode descrever a
maioria dos processos de Engenharia de Requisitos.
As atividades nem sempre ocorrem sequencialmente, em geral
realizam varias repetições ou são executadas paralelamente.
 Elicitação
 Análise e Negociação
 Especificação
 Validação
Processo de Engenharia de Requisitos
Elicitação dos Requisitos
O objetivo é obter conhecimentos relevantes do problema a ser resolvido.
Segundo Kotonya e Sommerville existem 4 dimensões na atividade de
elicitação de requisitos:
 Entendimento do domínio da aplicação – entendes-e a área na qual o
sistema será aplicado;
 Entendimento do problema – com auxilio do sistema a ser resolvido,
entende-se os detalhes do problema especifico a ser resolvido;
 Entendimento do negócio – entende-se qual a contribuição do
sistema para que sejam atingidos os objetivos gerais da organização;
 Entendimento das necessidades e das restrições dos stakeholders –
entende-se detalhadamente: as necessidades de apoio a serem
providas pelo sistema à realização do trabalho e aos interesses de
cada um dos stakeholders; os trabalhos a serem apoiados pelo
sistema e; o papel de eventuais sistemas existentes na execução e
condução dos processos de trabalho.
Análise e Negociação dos Requisitos
Depois da elicitação de requisitos todo esse conhecimento adquirido pelos
stakeholders precisa ser representado através de notações diversas. Essas
representações precisam estar sempre consistentes.
Negociação de requisitos é uma atividade extremamente complexa, ter um
entendimento global de todos os objetivos, soluções e interação entre eles é
uma tarefa muito difícil de executar. Assim existem diferentes métodos e
técnicas de negociação.
Robinson estabelece uma infraestrutura para modelar o processo de
negociação:
 Perspectivas de negociação
 Processos de negociação
 Produtos da negociação
Especificação dos Requisitos
Após serem identificados e analisados os requisitos devem ser documentados
para que possam servir de base para o resto do processo.
Administrar o volume de informações que são gerados pelo processo de
engenharia de requisitos é um dos principais problemas que se enfrenta na
documentação de requisitos. Para se tornar um pouco mais fácil a
administração desse documento usa-se uma notação gráfica que diminui o
tamanho do modelo.
Cada engenheiro de requisitos usa um modelo para fazer sua documentação.
A seguir são mostrados três modelos de documentos que são encontrados na
literatura:
Modelo 1 – Roger S. Pressman
Modelo 2 – RUP (Rational Unified Process)
Modelo 3 – Wilson de Pádua Filho
Validação dos Requisitos
Esta atividade acontece no final da especificação de requisitos e seu
objetivo é verificar se a documentação dos requisitos esta
consistente e se contem todas as necessidades dos usuários.
A revisão é uma das técnicas usadas para validar os requisitos.
Uma das maneiras para essa tarefa é utilizar um relatório de revisão.
Um grande desafio para a validação de requisitos é mostrar que a
especificação de requisitos está correta, pois não existe uma forma
para isso.
GERENCIAMENTO DE REQUISITOS
Gerenciamento de requisitos trata-se de um modelo sistemático pra
identificar, organizar e documentar os requisitos do sistema,
estabelecer e manter acordo entre o cliente e a equipe do projeto nos
requisitos variáveis do sistema.
Para ter um gerenciamento eficiente de requisitos é preciso:
 Manter uma declaração de requisitos clara;
 Atributos aplicáveis a cada tipo de requisito e;
 Rastreabilidade para outros requisitos e outros artefatos do
projeto.
GERENCIAMENTO DE REQUISITOS
Existem requisitos funcionais e não-funcionais. Exemplos:
 Funcional: o usuário deve selecionar a opção de inclusão para
cadastrar um novo aluno no banco de dados.
 Não-funcional: o sistema deve ser compatível com as
plataformas Windows e Linux.
 Não-funcional: o sistema deverá ser desenvolvido em Java.
É natural que alguns requisitos possam não ser definidos corretamente no
início do projeto, para isso serão necessárias várias revisões periódicas, a
fim de detectar erros o mais cedo possível e corrigi-los logo em seguida.
DISCIPLINA DE
ANÁLISE E PROJETO
("DESIGN")
 Após a etapa de análise de requisitos,
temos documentos de requisitos e os
casos de uso em mãos.
 Queremos agora gerar um primeiro
modelo do sistema a partir dos casos de
uso.
 Este é chamado de modelo de análise.
Requisitos Análise Projeto
 Vai proporcionar um método que permita que
criemos um modelo de classes do sistema a
partir dos casos de uso
 Trará a resposta para a pergunta:
◦ Quais classes preciso para implementar estes
casos de uso?
casos de uso análise
Descritos na linguagem do
cliente
Descrito na linguagem dos
desenvolvedores
Visão externa do sistema Visão interna do sistema
Captura as funcionalidades
do sistema
Mostra, de modo abstrato,
como a funcionalidade pode
ser realizada
Estruturado por casos
de uso
Estruturado por classes e
pacotes
 O modelo de análise e projeto contém as
realizações de casos de uso
 Pode ser particionado em dois modelos
◦ Modelo de Analise
◦ Modelo de Projeto
Diagramas de ClasseDiagramas de Classe
Realização de Caso
de Uso
Caso de Uso
Diagramas de ColaboraçãoDiagramas de Colaboração
Diagramas de SequênciaDiagramas de Sequência
Descreve como o
caso de uso é
realizado,
associando o caso
de uso com classes
e outros elementos
de projeto
 Requisitos   Analise e projeto 
MDS - Bacalá
Diagrama de
Atividades
1. Analisar Arquitetura
2. Analisar Caso de Uso
3. Projetar Classes
4. Projetar Banco de Dados
Interface Gráfica
Negócio
Dados
Módulo de Vendas
Módulo de
Estoque
Socket
Para cada caso de uso
 Identificar as classes de análise
• Classes de fronteira
• Classes de controle
• Classes de entidade
Para cada classe
 Identificar responsabilidades das classes
 Identificar relacionamentos
 Identificar atributos
Para cada classe
1. Criar classes de projeto
2. Identificar classes persistentes
3. Definir métodos
4. Definir atributos
5. Definir estados
6. Definir relacionamentos
7. Contemplar os requisitos não-funcionais
 Mapear as classes persistentes em conceitos
do Banco de Dados
 Definir os tipos de dados mais adequados para
o Banco de Dados
 Normalizar se necessário
DISCIPLINA DE
IMPLEMENTAÇÃO
Disciplina de Implementação
OBJETIVOS
 Definir a organização do código em termos de subsistemas de
implementação organizados em camadas
 Implementar classes e objetos em termos de componentes
(arquivos-fonte, binários, executáveis e outros)
 Testar os componentes desenvolvidos como unidades
 Integrar os resultados produzidos por implementadores
individuais (ou equipes) ao sistema executável
Modelo de projeto
Modelo de dados
Implementação
Documento da
arquitetura
Modelo de implementação
Componentes
Plano de Integração
Documento da
arquitetura
Estruturar Modelo de
Implementação
Revisor de Código
Programador
Integrador do
Sistema e
Subsistemas
Planejar Integração Integrar Sistema
e Subsistemas
Implementar
Componentes
Corrigir
Defeitos
Realizar Testes
de Unidade
Revisar
Código Fonte
 Identificar quais componentes participam da iteração (colaboram
para os casos de uso da iteração)
: C lie n t e
C o n t ro la d o r
C lie n t e
M a q u in a
D in h e iro
B a n c oLe it o ra C a rt a o C lie n t eF o rm u la rio
S a q u e
in s e re c a rt a o
in ic ia r s e s s a o (d a d o s c a rt a o )
s oli ci t a s e nh a
s o lic it a s e n h a
e n t ra s e n h a
e n t ra s e n h a
n e w C lie n t e (d a d o s c a rt a o , s e n h a )
v e rif ic a s e n h a
so lic it a v a lo r
s o lic it a v a lo r
e n t ra v a lo r
e n t ra v a lo r
v e rif ic a s a ld o (v a lo r)
s o lic it a d e b it o (v a lo r)
s ol ici t a d e v ol uc a o c art a o
s o lic it a e n t re g a d in h e iro
c a rt a o
d in h e iro
 Identificar quais pacotes participam da iteração (colaboram para
os casos de uso da iteração)
Applicação
Negócio
Middleware
Básico
*
*
*
*
*
Candidatos a Stubs
x
x
Aplicação
Comunicação
Negócio
Dados
3
Stubs2
2
1
1
aa bb
cc dd
ee gg
ff
hh ii jj
 Definir os builds que serão gerados
 Avaliar resultados
◦ A ordem de integração reduz a necessidade de
criação de stubs?
◦ A ordem de integração facilita a detecção de erros?
Estruturar Modelo de
Implementação
Revisor de Código
Programador
Integrador do
Sistema e
Subsistemas
Planejar Integração Integrar Sistema
e Subsistemas
Implementar
Componentes
Corrigir
Defeitos
Realizar Testes
de Unidade
Revisar
Código Fonte
 Modelo de Implementação
◦ Modelo de projeto gerado a partir da engenharia
reversa do código fonte do sistema
Estruturar Modelo de
Implementação
Revisor de Código
Programador
Integrador do
Sistema e
Subsistemas
Planejar Integração Integrar Sistema
e Subsistemas
Implementar
Componentes
Corrigir
Defeitos
Realizar Testes
de Unidade
Revisar
Código Fonte
 Check-out dos componentes
 Implementar
◦ Operações
◦ Inicialização dos atributos
◦ Estados
 Comentar o código implementado
◦ Seguindo um padrão de codificação
 Avaliar o código implementado
◦ Padrão de codificação
◦ Fatores de qualidade de OO e Java
 Compilar o código implementado
◦ Com a última versão estável dos componentes auxiliares
◦ Com a versão mais recente dos componentes
implementados
 Check-in dos componentes
Estruturar Modelo de
Implementação
Revisor de Código
Programador
Integrador do
Sistema e
Subsistemas
Planejar Integração Integrar Sistema
e Subsistemas
Implementar
Componentes
Corrigir
Defeitos
Realizar Testes
de Unidade
Revisar
Código Fonte
 Check-out dos componentes
 Estabilizar a ocorrência do defeito
◦ Identificar casos de teste mínimos que causam o defeito
 Localizar o defeito no código
◦ Isolado do ambiente de produção
◦ Com ferramenta de depuração
◦ Comentando trechos do código
◦ Criando stubs
 Corrigir o defeito no código
 Check-in dos componentes
Estruturar Modelo de
Implementação
Revisor de Código
Programador
Integrador do
Sistema e
Subsistemas
Planejar Integração Integrar Sistema
e Subsistemas
Implementar
Componentes
Corrigir
Defeitos
Realizar Testes
de Unidade
Revisar
Código Fonte
 Implementar componentes de teste
◦ Separados dos componentes a serem testados
◦ Usando ferramenta para geração dos componentes de teste
 Ex: Junit
◦ Aproveitando componentes implementados anteriormente
(Check-out)
 Check-in dos componentes de teste
 Executar testes e avaliar resultados
Estruturar Modelo de
Implementação
Revisor de Código
Programador
Integrador do
Sistema e
Subsistemas
Planejar Integração Integrar Sistema
e Subsistemas
Implementar
Componentes
Corrigir
Defeitos
Realizar Testes
de Unidade
Revisar
Código Fonte
 Revisar código
◦ Com base nos seguintes documentos:
 Padrão de codificação
 Fatores de qualidade de OO e Java
◦ Sem verificar se casos de uso foram corretamente
implementados
◦ Função corretiva, mas também educativa
 Passar mudanças para o programador responsável
Estruturar Modelo de
Implementação
Revisor de Código
Programador
Integrador do
Sistema e
Subsistemas
Planejar Integração Integrar Sistema
e Subsistemas
Implementar
Componentes
Corrigir
Defeitos
Realizar Testes
de Unidade
Revisar
Código Fonte
 Check-out de todos os componentes do
repositório principal
 Integrar componentes em um build
 Notificar responsável pelos defeitos
 Criar tag (identificador) para o build
 Divulgar o build
 Check-in dos componentes
DISCIPLINA DE
TESTE
Fluxo de Trabalho
Papéis e Atividades
Papéis e Artefatos
DISCIPLINA DE
IMPLANTAÇÃO
Finalidade: Descrever as atividades que garantam que o produto de
software será disponibilizado a seus usuários finais.
Disciplina de Implantação
Esta Disciplina descreve três modos de implantação de produto:
 A instalação personalizada
 O produto em uma forma "compacta"
 Acesso ao software por meio da Internet
Em cada instância, a ênfase é testar o produto no local de
desenvolvimento, seguido de testes beta, antes de ele ser finalmente
oferecido ao cliente.
Fluxo de Trabalho
Atividades
Os papéis envolvidos e os artefatos produzidos na
disciplina Implantação.
 Formado em Análise de Sistemas
 Pós-Graduado em Auditoria em T.I.
 Gerente de TI da CLIOC – Coleção de Leishmania do
Instituto Oswaldo Cruz – Fiocruz
 Certificado em Gestão de Segurança da Informação e
Gerenciamento de T.I. pela Academia Latino-Americana
(Microsoft TechNet / Módulo Security)
Carlos Henrique M. da Silva
carloshenrique.85@globo.com

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Modelo Incremental - Engenharia de Software
Modelo Incremental - Engenharia de SoftwareModelo Incremental - Engenharia de Software
Modelo Incremental - Engenharia de Software
 
Prototipação
PrototipaçãoPrototipação
Prototipação
 
Padrões MVC
Padrões MVCPadrões MVC
Padrões MVC
 
Arquitetura MVC
Arquitetura MVCArquitetura MVC
Arquitetura MVC
 
Diagrama de Casos de Uso
Diagrama de Casos de UsoDiagrama de Casos de Uso
Diagrama de Casos de Uso
 
Requisitos Ágeis
Requisitos ÁgeisRequisitos Ágeis
Requisitos Ágeis
 
Comandos do linux
Comandos do linuxComandos do linux
Comandos do linux
 
Caso De Uso
Caso De UsoCaso De Uso
Caso De Uso
 
Introdução à Qualidade e Testes Ágeis de Software
Introdução à Qualidade e Testes Ágeis de SoftwareIntrodução à Qualidade e Testes Ágeis de Software
Introdução à Qualidade e Testes Ágeis de Software
 
Modelos de Processo de Software
Modelos de Processo de SoftwareModelos de Processo de Software
Modelos de Processo de Software
 
Aula 06 - Diagrama de classes
Aula 06 - Diagrama de classesAula 06 - Diagrama de classes
Aula 06 - Diagrama de classes
 
Aula01-JavaScript
Aula01-JavaScriptAula01-JavaScript
Aula01-JavaScript
 
Introdução a Arquitetura de Sistemas
Introdução a Arquitetura de SistemasIntrodução a Arquitetura de Sistemas
Introdução a Arquitetura de Sistemas
 
Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
 
Aula 07 - Diagrama de sequencia
Aula 07 - Diagrama de sequenciaAula 07 - Diagrama de sequencia
Aula 07 - Diagrama de sequencia
 
Aula03 - JavaScript
Aula03 - JavaScriptAula03 - JavaScript
Aula03 - JavaScript
 
Testes de Software
Testes de SoftwareTestes de Software
Testes de Software
 
Aula 1 - Introdução a Engenharia de Software
Aula 1 -  Introdução a Engenharia de SoftwareAula 1 -  Introdução a Engenharia de Software
Aula 1 - Introdução a Engenharia de Software
 
Construir microservices em python nunca foi tão simples como com o Nameko!
Construir microservices em python nunca foi tão simples como com o Nameko!Construir microservices em python nunca foi tão simples como com o Nameko!
Construir microservices em python nunca foi tão simples como com o Nameko!
 
Mpsbr
MpsbrMpsbr
Mpsbr
 

Destaque

Engenharia Software Rup
Engenharia Software   RupEngenharia Software   Rup
Engenharia Software Rup
Felipe
 
Introdução à Engenharia de Requisitos e RUP
Introdução à Engenharia de Requisitos e RUPIntrodução à Engenharia de Requisitos e RUP
Introdução à Engenharia de Requisitos e RUP
Vagner Santana
 
Processo Unificado(RUP)
Processo Unificado(RUP)Processo Unificado(RUP)
Processo Unificado(RUP)
elliando dias
 
Introdução à Arquitetura Web
Introdução à Arquitetura WebIntrodução à Arquitetura Web
Introdução à Arquitetura Web
Breno Vitorino
 
Gerencia De Projetos Com RUP Cmm E Iso 9001
Gerencia De Projetos Com RUP Cmm E Iso 9001Gerencia De Projetos Com RUP Cmm E Iso 9001
Gerencia De Projetos Com RUP Cmm E Iso 9001
elliando dias
 
Diagrama de implantação
Diagrama de implantaçãoDiagrama de implantação
Diagrama de implantação
elliando dias
 

Destaque (20)

Engenharia Software Rup
Engenharia Software   RupEngenharia Software   Rup
Engenharia Software Rup
 
Apresentação RUP
Apresentação RUPApresentação RUP
Apresentação RUP
 
Introdução à Engenharia de Requisitos e RUP
Introdução à Engenharia de Requisitos e RUPIntrodução à Engenharia de Requisitos e RUP
Introdução à Engenharia de Requisitos e RUP
 
Rup e metodos ágies
Rup e metodos ágiesRup e metodos ágies
Rup e metodos ágies
 
Introdução ao RUP
Introdução ao RUPIntrodução ao RUP
Introdução ao RUP
 
Processo Unificado(RUP)
Processo Unificado(RUP)Processo Unificado(RUP)
Processo Unificado(RUP)
 
Introdução ao RUP
Introdução ao RUPIntrodução ao RUP
Introdução ao RUP
 
Visao Geral Rup
Visao Geral RupVisao Geral Rup
Visao Geral Rup
 
A disciplina Teste no RUP
A disciplina Teste no RUPA disciplina Teste no RUP
A disciplina Teste no RUP
 
EssUP - Essential Unified Process
EssUP - Essential Unified ProcessEssUP - Essential Unified Process
EssUP - Essential Unified Process
 
Introdução à Arquitetura Web
Introdução à Arquitetura WebIntrodução à Arquitetura Web
Introdução à Arquitetura Web
 
Apresentação modelagem de_negócio_rup
Apresentação modelagem de_negócio_rupApresentação modelagem de_negócio_rup
Apresentação modelagem de_negócio_rup
 
Gerencia De Projetos Com RUP Cmm E Iso 9001
Gerencia De Projetos Com RUP Cmm E Iso 9001Gerencia De Projetos Com RUP Cmm E Iso 9001
Gerencia De Projetos Com RUP Cmm E Iso 9001
 
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWAREANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
 
Boas práticas para implementação Mps.br utilizando a ferramenta Channel
Boas práticas para implementação Mps.br utilizando a ferramenta Channel Boas práticas para implementação Mps.br utilizando a ferramenta Channel
Boas práticas para implementação Mps.br utilizando a ferramenta Channel
 
R.U.P. - Razão Unitária de Produção na Construção Civil
R.U.P. - Razão Unitária de Produção na Construção CivilR.U.P. - Razão Unitária de Produção na Construção Civil
R.U.P. - Razão Unitária de Produção na Construção Civil
 
Comparativo entre Processos Ágeis
Comparativo entre Processos ÁgeisComparativo entre Processos Ágeis
Comparativo entre Processos Ágeis
 
Desenvolvimento de Software com Extreme Programming (XP)
Desenvolvimento de Software com Extreme Programming (XP)Desenvolvimento de Software com Extreme Programming (XP)
Desenvolvimento de Software com Extreme Programming (XP)
 
Diagrama de implantação
Diagrama de implantaçãoDiagrama de implantação
Diagrama de implantação
 
Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
 

Semelhante a Rational Unified Process (RUP)

Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
Roni Reis
 
Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9
wilsonguns
 
T1 g13.modelo cascata
T1 g13.modelo cascataT1 g13.modelo cascata
T1 g13.modelo cascata
wilsonguns
 
Engenharia de Software introdução
Engenharia de Software    introduçãoEngenharia de Software    introdução
Engenharia de Software introdução
miroslayer
 

Semelhante a Rational Unified Process (RUP) (20)

IBM Rational Unified Process
IBM Rational Unified ProcessIBM Rational Unified Process
IBM Rational Unified Process
 
Aula2 processos sw
Aula2 processos swAula2 processos sw
Aula2 processos sw
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
 
Es capítulo 2 - processos de software
Es   capítulo 2  - processos de softwareEs   capítulo 2  - processos de software
Es capítulo 2 - processos de software
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De Software
 
38484931 questionario-es
38484931 questionario-es38484931 questionario-es
38484931 questionario-es
 
O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdfO_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
 
Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9
 
Aula_4_e_5_-_RUP_Rapid_Unified_Process_Software_Engineering
Aula_4_e_5_-_RUP_Rapid_Unified_Process_Software_EngineeringAula_4_e_5_-_RUP_Rapid_Unified_Process_Software_Engineering
Aula_4_e_5_-_RUP_Rapid_Unified_Process_Software_Engineering
 
Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
 
Analise sistemas 05
Analise sistemas 05Analise sistemas 05
Analise sistemas 05
 
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
 
347842.ppt
347842.ppt347842.ppt
347842.ppt
 
Métodos ágeis de desenvolvimento2
Métodos ágeis de desenvolvimento2Métodos ágeis de desenvolvimento2
Métodos ágeis de desenvolvimento2
 
T1 g13.modelo cascata
T1 g13.modelo cascataT1 g13.modelo cascata
T1 g13.modelo cascata
 
Aula 03 - IBM Rational Unified Process- METODOLOGIA ÁGIL
Aula 03 - IBM Rational Unified Process- METODOLOGIA ÁGILAula 03 - IBM Rational Unified Process- METODOLOGIA ÁGIL
Aula 03 - IBM Rational Unified Process- METODOLOGIA ÁGIL
 
Análise e Design Orientado a Objetos.ppt
Análise e Design Orientado a Objetos.pptAnálise e Design Orientado a Objetos.ppt
Análise e Design Orientado a Objetos.ppt
 
FDD
FDDFDD
FDD
 
Engenharia de Software introdução
Engenharia de Software    introduçãoEngenharia de Software    introdução
Engenharia de Software introdução
 
Aula 7 - Ciclo de vida do software.pptx
Aula 7 - Ciclo de vida do software.pptxAula 7 - Ciclo de vida do software.pptx
Aula 7 - Ciclo de vida do software.pptx
 

Mais de Carlos Henrique Martins da Silva

Mais de Carlos Henrique Martins da Silva (16)

Segurança da Informação Aplicada a Negócios
Segurança da Informação Aplicada a NegóciosSegurança da Informação Aplicada a Negócios
Segurança da Informação Aplicada a Negócios
 
eXtensible Markup Language (XML)
eXtensible Markup Language (XML)eXtensible Markup Language (XML)
eXtensible Markup Language (XML)
 
eXtreme Programming (XP)
eXtreme Programming (XP)eXtreme Programming (XP)
eXtreme Programming (XP)
 
Aula 9 - Backdoor
Aula 9 - BackdoorAula 9 - Backdoor
Aula 9 - Backdoor
 
Aula 8 - SQL Injection
Aula 8 - SQL InjectionAula 8 - SQL Injection
Aula 8 - SQL Injection
 
Aula 7 - Ataque de Força Bruta
Aula 7 - Ataque de Força BrutaAula 7 - Ataque de Força Bruta
Aula 7 - Ataque de Força Bruta
 
Aula 6 - Ataques de Negação de Serviço (DoS e D-DoS)
Aula 6 - Ataques de Negação de Serviço (DoS e D-DoS)Aula 6 - Ataques de Negação de Serviço (DoS e D-DoS)
Aula 6 - Ataques de Negação de Serviço (DoS e D-DoS)
 
Aula 5 - Assinatura e Certificado Digital
Aula 5 - Assinatura e Certificado DigitalAula 5 - Assinatura e Certificado Digital
Aula 5 - Assinatura e Certificado Digital
 
Aula 4 - Plano de Continuidade de Negócios (PCN)
Aula 4 - Plano de Continuidade de Negócios (PCN)Aula 4 - Plano de Continuidade de Negócios (PCN)
Aula 4 - Plano de Continuidade de Negócios (PCN)
 
Aula 3 - Política de Segurança da Informação (PSI)
Aula 3 - Política de Segurança da Informação (PSI)Aula 3 - Política de Segurança da Informação (PSI)
Aula 3 - Política de Segurança da Informação (PSI)
 
Aula 2 - Gestão de Riscos
Aula 2 - Gestão de RiscosAula 2 - Gestão de Riscos
Aula 2 - Gestão de Riscos
 
Aula 10 - Cross Site Scripting (XSS)
Aula 10 - Cross Site Scripting (XSS)Aula 10 - Cross Site Scripting (XSS)
Aula 10 - Cross Site Scripting (XSS)
 
Aula 1 - Introdução a Segurança da Informação
Aula 1 - Introdução a Segurança da InformaçãoAula 1 - Introdução a Segurança da Informação
Aula 1 - Introdução a Segurança da Informação
 
Deep web
Deep webDeep web
Deep web
 
Segurança Através de Controles Biométricos - Carlos Henrique Martins da Silva
Segurança Através de Controles Biométricos - Carlos Henrique Martins da SilvaSegurança Através de Controles Biométricos - Carlos Henrique Martins da Silva
Segurança Através de Controles Biométricos - Carlos Henrique Martins da Silva
 
Invasão e Segurança
Invasão e SegurançaInvasão e Segurança
Invasão e Segurança
 

Rational Unified Process (RUP)

  • 1. Carlos Henrique M. da Silva carloshenrique.85@globo.com
  • 2. 1. Histórico e Conceitos 2. Melhores práticas 3. Fases 4. Disciplinas
  • 3. O RUP, Processo Unificado Racional é um processo proprietário de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM, ganhando um novo nome IRUP e tornando-se uma brand na área de Software, fornecendo técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade no processo de desenvolvimento. O RUP usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos em ação. Utiliza técnicas e práticas aprovadas comercialmente.
  • 4. O RUP é, por si só, um produto de software. É modular e automatizado, e toda a sua metodologia é apoiada por diversas ferramentas de desenvolvimento integradas e vendidas pela IBM através de seus "Rational Suites". Métodos concorrentes no campo da engenharia de software incluem o "Cleanroom" (considerado pesado) e os Métodos Ágeis (leves) como a Programação Extrema (XP), Scrum, FDD (Desenvolvimento Guiado por Funcionalidades) entre outros. Objetivo é assegurar a produção de software de alta qualidade dentro de prazos e orçamentos previsíveis (Kruchten 2003, pág. 14)
  • 5. O RUP define perfeitamente quem é responsável pelo que, como as coisas deverão ser feitas e quando devem ser realizadas, descrevendo todas as metas de desenvolvimento especificamente para que sejam alcançadas. Oferece uma abordagem organizada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento.
  • 6. Melhores Práticas  Desenvolver software iterativamente  Gestão de requisitos  Uso de arquitetura baseada em componentes  Uso de software de modelos visuais  Verificação da qualidade do software  Gestão e Controle de Mudanças do Software
  • 7. Desenvolver Software Iterativamente Desenvolver iterativamente significa desenvolver em ciclos. Cada ciclo é contém um objetivo que deve ser alcançado (lançamento de um pré release ou beta, correção de um bug, etc.) Esta prática acaba dando ao RUP uma série de vantagens, como:  Possibilidade de identificar/modificar requerimentos com mais facilidade;  Integração progressiva (quase continua) de elementos ao software, ocasionando uma melhora no descobrimento e endereçamento de riscos;  Desenvolvimento iterativo provê aos gerentes maneiras de fazer mudanças táticas aos produtos; etc.
  • 8. Gestão de Requisitos O gerenciamento de recursos acarreta um melhor controle sobre projetos complexos, além de maior qualidade e redução de custos. O RUP é uma metodologia dirigida-a-casos-de-uso (use- drivencase), de modo que é possível utilizar os mesmos casos de uso definidos no sistema como base para o resto do processo. Os casos de uso (em inglês Use Cases) e os cenários são exemplos de artefatos dependentes do processo, que têm sido considerados muito mais eficazes na captura de requisitos funcionais.
  • 9. Arquitetura Baseada em Componentes Um componente normalmente se relaciona com um objeto na programação orientada a objetos. O RUP oferece uma forma sistemática para construir este tipo de sistema, focando-se em produzir uma arquitetura executável nas fases iniciais do projeto, ou seja, antes de comprometer recursos em larga escala. Estes componentes são normalmente incluídos em infraestruturas existentes como o CORBA e o COM (Modelo de Componentes de Objetos).
  • 10. Uso de Software de Modelos Visuais A modelagem visual permite melhor entender não só a concepção e a complexidade do sistema, mas também “dimensionar” (no sentido de qual a forma do sistema), além de facilitar a identificação e solução de problemas.
  • 11. Verificação da qualidade do software Não assegurar a qualidade do software é a falha mais comum em todos os projetos de sistemas computacionais. Normalmente pensa- se em qualidade de software após o término dos projetos, ou a qualidade é responsabilidade de uma equipe diferente da equipe de desenvolvimento. O RUP não toma a qualidade como responsabilidade de apenas uma pessoa ou grupo, mas como uma responsabilidade de todos os integrantes do projeto. A qualidade é focada especialmente em duas áreas:  Qualidade de produto: Sendo desenvolvido (software ou sistema) e todos as partes envolvidas (componentes, subsistemas, arquitetura).  Qualidade de processo: Dentro do projeto de desenvolvimento.
  • 12. Gestão e Controle de Mudanças do Software Em todos os projetos de software a existência de mudanças é inevitável. O RUP define métodos para controlar e monitorar mudanças. Como uma pequena mudança pode afetar aplicações de formas inteiramente imprevisíveis, o controle de mudanças é essencial para o sucesso de um projeto. O RUP também define áreas de trabalho seguras, garantindo a um programador que as mudanças efetuadas noutro sistema não afetarão o seu sistema.
  • 13. Fases de Desenvolvimento Até agora estas linhas de guia são gerais, a serem aderidas ao percorrer do ciclo de vida de um projeto. As fases indicam a ênfase que é dada no projeto em um dado instante. Para capturar a dimensão do tempo de um projeto, o RUP divide o projeto em quatro fases diferentes: 1. Concepção: ênfase no escopo do sistema; 2. Elaboração: ênfase na arquitetura; 3. Construção: ênfase no desenvolvimento; 4. Transição: ênfase na implantação.
  • 14. Fases de Desenvolvimento O RUP também se baseia nos 4 Ps: 1. Pessoas 2. Projeto 3. Produto 4. Processo As fases são compostas de iterações. As iterações são janelas de tempo; as iterações possuem prazo definido enquanto as fases são objetivas. Todas as fases geram artefatos. Estes serão utilizados nas próximas fases e documentam o projeto, além de permitir melhor acompanhamento.
  • 15. Fase de Concepção Esta fase do RUP abrange as tarefas de comunicação com o cliente e planejamento. É feito um plano de projeto avaliando os possíveis riscos, as estimativas de custo e prazos, estabelecendo as prioridades, levantamento dos requisitos do sistema e preliminarmente analisá- lo. Assim, haverá uma anuência das partes interessadas na definição do escopo do projeto, onde são examinados os objetivos para se decidir sobre a continuidade do desenvolvimento.
  • 16. Fase de Elaboração Abrange a Modelagem do modelo genérico do processo. O objetivo desta fase é analisar de forma mais detalhada a análise do domínio do problema, revisando os riscos que o projeto pode sofrer e a arquitetura do projeto começa a ter sua forma básica. Indagações como “O plano do projeto é confiável?”, “Os custos são admissíveis?” são esclarecidas nesta etapa.
  • 17. Fase de Construção Desenvolve ou Adquire os componentes de Software. O principal objetivo desta fase é a construção do sistema de software, com foco no desenvolvimento de componentes e outros recursos do sistema. É na fase de Construção que a maior parte de codificação ocorre.
  • 18. Fase de Transição Abrange a entrega do software ao usuário e a fase de testes. O objetivo desta fase é disponibilizar o sistema, tornando-o disponível e compreendido pelo usuário final. As atividades desta fase incluem o treinamento dos usuários finais e também a realização de testes da versão beta do sistema visando garantir que o mesmo possua o nível adequado de qualidade.
  • 19. Disciplinas As disciplinas descrevem o aspecto estático do processo, como ele é descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papéis do processo. São divididas em:  Seis Disciplinas de Engenharia  Modelagem de Negócios  Requisitos  Análise e Projeto ("Design")  Implementação  Teste  Implantação  Três Disciplinas de Apoio/Suporte  Ambiente  Configuração e Gerência de Mudança  Gerência de Projeto
  • 20. Engenharia - Disciplina de Modelagem de Negócios Modelagem de negócios, explica como descrever uma visão da organização na qual o sistema será implantado e como usar esta visão como uma base para descrever o processo, papéis e responsabilidades. O objetivo de modelagem de negócios é, primeiramente, estabelecer uma melhor compreensão e canal de comunicação entre engenharia de negócios e engenharia de software. Compreender o negócio significa que os engenheiros de software devem compreender a estrutura e a dinâmica da empresa alvo (o cliente), os atuais problemas na organização e possíveis melhorias.
  • 21. Engenharia - Disciplina de Requisitos Esta disciplina explica como levantar pedidos das partes interessadas ("stakeholders") e transformá-los em um conjunto de requisitos que os produtos funcionam no âmbito do sistema a ser construído e fornecem requisitos detalhados para o que deve fazer o sistema.
  • 22. Engenharia - Disciplina de Análise e Projeto (“Design”) O objetivo da análise e projeto é mostrar como o sistema vai ser realizado. O objetivo é construir um sistema que:  Execute as tarefas e funções especificadas nas descrições;  Cumpra todas as suas necessidades;  Seja fácil de manter quando ocorrerem mudanças de requisitos funcionais.
  • 23. Engenharia - Disciplina de Implementação Os efeitos da implementação são:  Para definir a organização do código, em termos de subsistemas de implementação organizadas em camadas  Para implementar classes e objetos em termos de componentes (arquivos-fonte, binários, executáveis e outros)  Para testar os componentes desenvolvidos como unidades  Integrar os resultados produzidos por implementadores individuais (ou equipes), em um sistema executável
  • 24. Engenharia - Disciplina de Teste As finalidades da disciplina de teste são:  Verificar a interação entre objetos  Verificar a integração adequada dos componentes do software  Verificar se todos os requisitos foram corretamente implementados  Identificar e garantir que os defeitos são abordados antes da implantação do software  Garantir que todos os defeitos são corrigidos, reanalisados e fechados O RUP propõe uma abordagem iterativa, o que significa que deve-se testar todo o projeto. Os testes são realizados ao longo de 4 dimensões da qualidade: Confiabilidade, Funcionalidade, Desempenho da aplicação, e o Desempenho do sistema.
  • 25. Engenharia - Disciplina de Implantação O objetivo da implantação é o de produzir com sucesso lançamentos de produtos e entregar o software para seus usuários finais. Ele cobre uma vasta gama de atividades, incluindo a produção de releases externos do software, a embalagem do software e aplicativos de negócios, distribuição do software, instalação do software e prestação de ajuda e assistência aos usuários. Embora as atividades de implantação estejam principalmente centradas em torno da fase de transição, muitas das atividades devem ser incluídas nas fases anteriores para se preparar para a implantação, no final da fase de construção. Os processos ("workflows") de "Implantação e Ambiente" do RUP contêm menos detalhes do que outros workflows.
  • 26. Apoio/Suporte - Disciplina de Ambiente O ambiente enfoca as atividades necessárias para configurar o processo para um projeto. Ele descreve as atividades necessárias para desenvolver as diretrizes de apoio a um projeto. A proposta das atividades de ambiente é prover à organização de desenvolvimento de software os processos e as ferramentas que darão suporte à equipe de desenvolvimento. Se os usuários do RUP não entendem que o RUP é um framework de processo, eles podem percebê-lo como um processo pesado e caro.
  • 27. Apoio/Suporte - Disciplina de Configuração e Gerência de Mudança A disciplina de Gestão de Mudança em negócios com RUP abrange três gerenciamentos específicos: de configuração, de solicitações de mudança, e de status e medição. A Rational também tem um produto para manter as solicitações de mudança chamado ClearQuest.
  • 28. Apoio/Suporte - Disciplina de Gerência de Projeto Esta disciplina concentra-se principalmente sobre os aspectos importantes de um processo de desenvolvimento iterativo: Gestão de riscos; Planejamento de um projeto iterativo através do ciclo de vida e para uma iteração particular; E o processo de acompanhamento de um projeto iterativo, métricas. No entanto, esta disciplina do RUP não tenta cobrir todos os aspectos do gerenciamento de projetos. Por exemplo, não abrange questões como:  Gestão de Pessoas: contratação, treinamento, etc.  Orçamento Geral: definição, alocação, etc.  Gestão de Contratos: com fornecedores, clientes, etc.
  • 29. Embora o RUP não seja um processo adequado a todos os tipos de desenvolvimento de software, ele representa uma nova geração de processos genéricos. A mais importante inovação é a separação de fases e workflows, e o reconhecimento de que a implantação de software no ambiente do usuário é parte do processo. As fases são dinâmicas e tem objetivos. Os workflows são estáticos e constituem atividades técnicas que não estão associadas a uma única fase, mas podem ser utilizados ao longo do desenvolvimento para atingir os objetivos de cada fase (Sommerville 2007, pág. 56). Conclusão
  • 31. DISCIPLINAS Vamos agorar conhecer um pouco mais sobre as 6 disciplinas de engenharia do RUP: Modelagem de Negócios Requisitos Análise e Projeto ("Design") Implementação Teste Implantação
  • 33. Modelagem de Negócios É uma das 9 disciplinas do RUP e a primeira das 6 consideradas “core disciplines”. Dentro do ciclo de desenvolvimento de software podemos dizer que essa é sem dúvida a disciplina menos praticada. RUP não define esta como uma disciplina obrigatória, mas recomenda fortemente que ela seja executada especialmente para empresas que estão iniciando um novo negócio e não possuam uma clara modelagem do negócio.
  • 34. Modelagem de Negócios Finalidades:  Entender os problemas da organização identificando as possíveis melhorias;  Avaliar o impacto de mudanças na organização;  Assegurar que os clientes, usuários, desenvolvedores e outros parceiros tenham uma compreensão comum da organização;  Gerar conteúdo para a fase de requisitos do sistema que suportará a organização e seus processos;  Entender como o software se ajustará à organização.
  • 35. Modelagem de Negócios Papéis e Artefatos A importância da definição de papéisnão é somente para melhorar divisão do trabalho, mas principalmente para que hajana equipe responsabilidades definidas para cada atividade realizada, fazendo, assim,com que os membros tenham que cumprir direitinho as suas tarefas e que respondam por elas.  Gerente de Projeto  Analista de Processos de Negócio (Dentro da disciplina de Modelagem de Negócios, esse é o papel mais importante)  Designer de Negócio
  • 36. Gerente de Projeto Talvez seja um dos únicos papéis que estarão presentes em todos os projetos e em todas as suas fases, independente do tamanho, natureza ou metodologia de desenvolvimento adotada. Inicialmente, o gerente de projeto era o indivíduo que identificava as tarefas necessárias, as delegava aos membros da equipe e ficava pressionando cada um para cumprir os prazos. Hoje, essa realidade mudou. O gerente de projeto é um indivíduo extremamente participativo: realiza parcerias com os membros da equipe, estimula e valoriza as soluções encontradas e conduz o andamento do projeto, protegendo a equipe de distrações e organizando cronogramas, defende os interesses do time e realiza a comunicação com o cliente. Modelagem de Negócios
  • 37. Analista de Processos de Negócio Modelagem de Negócios
  • 39. Modelagem de Negócios Relação com Outras Disciplinas A disciplina Requisitos utiliza modelos de negócios como um importante subsídio para entender os requisitos do sistema. A disciplina Análise e Design utiliza entidades de negócios como subsídio para identificar classes de entidade no modelo de design. A disciplina Ambiente desenvolve e mantém artefatos de suporte, como o Guia de Modelagem de Negócios.
  • 41. O objetivo da disciplina Requisitos é descrever o que o sistema deve fazer e permite que desenvolvedores e clientes concordem com essa descrição. Para conseguir isso, obter, organizar e funcionalidade documento desejado e restrições; acompanhar e documentar compromissos e decisões. Uma visão do documento é criada, e necessidades das partes interessadas são extraídas. Atores e casos de uso são identificados. REQUISITOS
  • 42. O QUE É UM REQUISITO?  Condição ou capacidade que um sistema deve desempenhar  Qualidade de software  Funcionalidade: requisitos funcionais  Requisitos não funcionais  Usabilidade  Confiabilidade  Performance  Suportabilidade – manutenabilidade
  • 43. TIPOS DE REQUISITOS  Serviços (features)  Expressões de comportamento do sistema em alto nível (o quê)  Solicitações dos stakeholders  Requisitos do software  Requisitos de casos de usos
  • 44. Processo de levantamento de requisitos proposto pelo RUP (José Martins, 2004) REQUISITOS
  • 47. ENGENHARIA DE REQUISITOS É fundamental para o desenvolvimento de um software a compreensão dos requisitos. Se a análise e a especificação das funções não forem definidas adequadamente o software não atenderá as necessidades do usuário. A Engenharia de Requisito tem como objetivo a elaboração de um documento com as características do sistema. Este documento serve de referência para todas as pessoas envolvidas no processo de desenvolvimento inclusive os clientes. Com a chegada da engenharia de requisitos, se fez necessário à elaboração de um processo visando organizar as atividades. É o que analisaremos nos tópicos abaixo.
  • 48. Processo de Engenharia de Requisitos O processo de Engenharia de Requisitos é um conjunto de atividades a serem seguidas para desenvolver um documento de requisitos. Sommerville sugere um modelo de atividades que pode descrever a maioria dos processos de Engenharia de Requisitos. As atividades nem sempre ocorrem sequencialmente, em geral realizam varias repetições ou são executadas paralelamente.  Elicitação  Análise e Negociação  Especificação  Validação
  • 49. Processo de Engenharia de Requisitos
  • 50. Elicitação dos Requisitos O objetivo é obter conhecimentos relevantes do problema a ser resolvido. Segundo Kotonya e Sommerville existem 4 dimensões na atividade de elicitação de requisitos:  Entendimento do domínio da aplicação – entendes-e a área na qual o sistema será aplicado;  Entendimento do problema – com auxilio do sistema a ser resolvido, entende-se os detalhes do problema especifico a ser resolvido;  Entendimento do negócio – entende-se qual a contribuição do sistema para que sejam atingidos os objetivos gerais da organização;  Entendimento das necessidades e das restrições dos stakeholders – entende-se detalhadamente: as necessidades de apoio a serem providas pelo sistema à realização do trabalho e aos interesses de cada um dos stakeholders; os trabalhos a serem apoiados pelo sistema e; o papel de eventuais sistemas existentes na execução e condução dos processos de trabalho.
  • 51. Análise e Negociação dos Requisitos Depois da elicitação de requisitos todo esse conhecimento adquirido pelos stakeholders precisa ser representado através de notações diversas. Essas representações precisam estar sempre consistentes. Negociação de requisitos é uma atividade extremamente complexa, ter um entendimento global de todos os objetivos, soluções e interação entre eles é uma tarefa muito difícil de executar. Assim existem diferentes métodos e técnicas de negociação. Robinson estabelece uma infraestrutura para modelar o processo de negociação:  Perspectivas de negociação  Processos de negociação  Produtos da negociação
  • 52. Especificação dos Requisitos Após serem identificados e analisados os requisitos devem ser documentados para que possam servir de base para o resto do processo. Administrar o volume de informações que são gerados pelo processo de engenharia de requisitos é um dos principais problemas que se enfrenta na documentação de requisitos. Para se tornar um pouco mais fácil a administração desse documento usa-se uma notação gráfica que diminui o tamanho do modelo. Cada engenheiro de requisitos usa um modelo para fazer sua documentação. A seguir são mostrados três modelos de documentos que são encontrados na literatura: Modelo 1 – Roger S. Pressman Modelo 2 – RUP (Rational Unified Process) Modelo 3 – Wilson de Pádua Filho
  • 53. Validação dos Requisitos Esta atividade acontece no final da especificação de requisitos e seu objetivo é verificar se a documentação dos requisitos esta consistente e se contem todas as necessidades dos usuários. A revisão é uma das técnicas usadas para validar os requisitos. Uma das maneiras para essa tarefa é utilizar um relatório de revisão. Um grande desafio para a validação de requisitos é mostrar que a especificação de requisitos está correta, pois não existe uma forma para isso.
  • 54. GERENCIAMENTO DE REQUISITOS Gerenciamento de requisitos trata-se de um modelo sistemático pra identificar, organizar e documentar os requisitos do sistema, estabelecer e manter acordo entre o cliente e a equipe do projeto nos requisitos variáveis do sistema. Para ter um gerenciamento eficiente de requisitos é preciso:  Manter uma declaração de requisitos clara;  Atributos aplicáveis a cada tipo de requisito e;  Rastreabilidade para outros requisitos e outros artefatos do projeto.
  • 55. GERENCIAMENTO DE REQUISITOS Existem requisitos funcionais e não-funcionais. Exemplos:  Funcional: o usuário deve selecionar a opção de inclusão para cadastrar um novo aluno no banco de dados.  Não-funcional: o sistema deve ser compatível com as plataformas Windows e Linux.  Não-funcional: o sistema deverá ser desenvolvido em Java. É natural que alguns requisitos possam não ser definidos corretamente no início do projeto, para isso serão necessárias várias revisões periódicas, a fim de detectar erros o mais cedo possível e corrigi-los logo em seguida.
  • 56.
  • 57. DISCIPLINA DE ANÁLISE E PROJETO ("DESIGN")
  • 58.  Após a etapa de análise de requisitos, temos documentos de requisitos e os casos de uso em mãos.  Queremos agora gerar um primeiro modelo do sistema a partir dos casos de uso.  Este é chamado de modelo de análise.
  • 60.  Vai proporcionar um método que permita que criemos um modelo de classes do sistema a partir dos casos de uso  Trará a resposta para a pergunta: ◦ Quais classes preciso para implementar estes casos de uso?
  • 61. casos de uso análise Descritos na linguagem do cliente Descrito na linguagem dos desenvolvedores Visão externa do sistema Visão interna do sistema Captura as funcionalidades do sistema Mostra, de modo abstrato, como a funcionalidade pode ser realizada Estruturado por casos de uso Estruturado por classes e pacotes
  • 62.  O modelo de análise e projeto contém as realizações de casos de uso  Pode ser particionado em dois modelos ◦ Modelo de Analise ◦ Modelo de Projeto
  • 63. Diagramas de ClasseDiagramas de Classe Realização de Caso de Uso Caso de Uso Diagramas de ColaboraçãoDiagramas de Colaboração Diagramas de SequênciaDiagramas de Sequência Descreve como o caso de uso é realizado, associando o caso de uso com classes e outros elementos de projeto  Requisitos   Analise e projeto 
  • 64. MDS - Bacalá Diagrama de Atividades
  • 65.
  • 66. 1. Analisar Arquitetura 2. Analisar Caso de Uso 3. Projetar Classes 4. Projetar Banco de Dados
  • 67. Interface Gráfica Negócio Dados Módulo de Vendas Módulo de Estoque Socket
  • 68. Para cada caso de uso  Identificar as classes de análise • Classes de fronteira • Classes de controle • Classes de entidade Para cada classe  Identificar responsabilidades das classes  Identificar relacionamentos  Identificar atributos
  • 69. Para cada classe 1. Criar classes de projeto 2. Identificar classes persistentes 3. Definir métodos 4. Definir atributos 5. Definir estados 6. Definir relacionamentos 7. Contemplar os requisitos não-funcionais
  • 70.  Mapear as classes persistentes em conceitos do Banco de Dados  Definir os tipos de dados mais adequados para o Banco de Dados  Normalizar se necessário
  • 72.
  • 73. Disciplina de Implementação OBJETIVOS  Definir a organização do código em termos de subsistemas de implementação organizados em camadas  Implementar classes e objetos em termos de componentes (arquivos-fonte, binários, executáveis e outros)  Testar os componentes desenvolvidos como unidades  Integrar os resultados produzidos por implementadores individuais (ou equipes) ao sistema executável
  • 74.
  • 75. Modelo de projeto Modelo de dados Implementação Documento da arquitetura Modelo de implementação Componentes Plano de Integração Documento da arquitetura
  • 76. Estruturar Modelo de Implementação Revisor de Código Programador Integrador do Sistema e Subsistemas Planejar Integração Integrar Sistema e Subsistemas Implementar Componentes Corrigir Defeitos Realizar Testes de Unidade Revisar Código Fonte
  • 77.  Identificar quais componentes participam da iteração (colaboram para os casos de uso da iteração) : C lie n t e C o n t ro la d o r C lie n t e M a q u in a D in h e iro B a n c oLe it o ra C a rt a o C lie n t eF o rm u la rio S a q u e in s e re c a rt a o in ic ia r s e s s a o (d a d o s c a rt a o ) s oli ci t a s e nh a s o lic it a s e n h a e n t ra s e n h a e n t ra s e n h a n e w C lie n t e (d a d o s c a rt a o , s e n h a ) v e rif ic a s e n h a so lic it a v a lo r s o lic it a v a lo r e n t ra v a lo r e n t ra v a lo r v e rif ic a s a ld o (v a lo r) s o lic it a d e b it o (v a lo r) s ol ici t a d e v ol uc a o c art a o s o lic it a e n t re g a d in h e iro c a rt a o d in h e iro
  • 78.  Identificar quais pacotes participam da iteração (colaboram para os casos de uso da iteração) Applicação Negócio Middleware Básico * * * * * Candidatos a Stubs x x
  • 79. Aplicação Comunicação Negócio Dados 3 Stubs2 2 1 1 aa bb cc dd ee gg ff hh ii jj  Definir os builds que serão gerados
  • 80.  Avaliar resultados ◦ A ordem de integração reduz a necessidade de criação de stubs? ◦ A ordem de integração facilita a detecção de erros?
  • 81. Estruturar Modelo de Implementação Revisor de Código Programador Integrador do Sistema e Subsistemas Planejar Integração Integrar Sistema e Subsistemas Implementar Componentes Corrigir Defeitos Realizar Testes de Unidade Revisar Código Fonte
  • 82.  Modelo de Implementação ◦ Modelo de projeto gerado a partir da engenharia reversa do código fonte do sistema
  • 83. Estruturar Modelo de Implementação Revisor de Código Programador Integrador do Sistema e Subsistemas Planejar Integração Integrar Sistema e Subsistemas Implementar Componentes Corrigir Defeitos Realizar Testes de Unidade Revisar Código Fonte
  • 84.  Check-out dos componentes  Implementar ◦ Operações ◦ Inicialização dos atributos ◦ Estados  Comentar o código implementado ◦ Seguindo um padrão de codificação
  • 85.  Avaliar o código implementado ◦ Padrão de codificação ◦ Fatores de qualidade de OO e Java  Compilar o código implementado ◦ Com a última versão estável dos componentes auxiliares ◦ Com a versão mais recente dos componentes implementados  Check-in dos componentes
  • 86. Estruturar Modelo de Implementação Revisor de Código Programador Integrador do Sistema e Subsistemas Planejar Integração Integrar Sistema e Subsistemas Implementar Componentes Corrigir Defeitos Realizar Testes de Unidade Revisar Código Fonte
  • 87.  Check-out dos componentes  Estabilizar a ocorrência do defeito ◦ Identificar casos de teste mínimos que causam o defeito  Localizar o defeito no código ◦ Isolado do ambiente de produção ◦ Com ferramenta de depuração ◦ Comentando trechos do código ◦ Criando stubs  Corrigir o defeito no código  Check-in dos componentes
  • 88. Estruturar Modelo de Implementação Revisor de Código Programador Integrador do Sistema e Subsistemas Planejar Integração Integrar Sistema e Subsistemas Implementar Componentes Corrigir Defeitos Realizar Testes de Unidade Revisar Código Fonte
  • 89.  Implementar componentes de teste ◦ Separados dos componentes a serem testados ◦ Usando ferramenta para geração dos componentes de teste  Ex: Junit ◦ Aproveitando componentes implementados anteriormente (Check-out)  Check-in dos componentes de teste  Executar testes e avaliar resultados
  • 90. Estruturar Modelo de Implementação Revisor de Código Programador Integrador do Sistema e Subsistemas Planejar Integração Integrar Sistema e Subsistemas Implementar Componentes Corrigir Defeitos Realizar Testes de Unidade Revisar Código Fonte
  • 91.  Revisar código ◦ Com base nos seguintes documentos:  Padrão de codificação  Fatores de qualidade de OO e Java ◦ Sem verificar se casos de uso foram corretamente implementados ◦ Função corretiva, mas também educativa  Passar mudanças para o programador responsável
  • 92. Estruturar Modelo de Implementação Revisor de Código Programador Integrador do Sistema e Subsistemas Planejar Integração Integrar Sistema e Subsistemas Implementar Componentes Corrigir Defeitos Realizar Testes de Unidade Revisar Código Fonte
  • 93.  Check-out de todos os componentes do repositório principal  Integrar componentes em um build  Notificar responsável pelos defeitos  Criar tag (identificador) para o build  Divulgar o build  Check-in dos componentes
  • 99. Finalidade: Descrever as atividades que garantam que o produto de software será disponibilizado a seus usuários finais. Disciplina de Implantação Esta Disciplina descreve três modos de implantação de produto:  A instalação personalizada  O produto em uma forma "compacta"  Acesso ao software por meio da Internet Em cada instância, a ênfase é testar o produto no local de desenvolvimento, seguido de testes beta, antes de ele ser finalmente oferecido ao cliente.
  • 102. Os papéis envolvidos e os artefatos produzidos na disciplina Implantação.
  • 103.  Formado em Análise de Sistemas  Pós-Graduado em Auditoria em T.I.  Gerente de TI da CLIOC – Coleção de Leishmania do Instituto Oswaldo Cruz – Fiocruz  Certificado em Gestão de Segurança da Informação e Gerenciamento de T.I. pela Academia Latino-Americana (Microsoft TechNet / Módulo Security) Carlos Henrique M. da Silva carloshenrique.85@globo.com