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)
Oferece uma abordagem organizada em disciplinas para atribuir
tarefas e responsabilidades dentro de uma organização de
desenvolvimento.

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

 Conclusão
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).
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
 Modelagem de Negócios
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
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
 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.
 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

 REQUISITOS
Processo de levantamento de requisitos
proposto pelo RUP (José Martins, 2004)
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 Descrito na linguagem dos
cliente desenvolvedores

Visão externa do sistema Visão interna do sistema

Mostra, de modo abstrato,

Captura as funcionalidades
como a funcionalidade pode
do sistema
ser realizada
Estruturado por casos Estruturado por classes e
de uso 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
 Caso de Uso Realização de Caso
de Uso

Descreve como o
caso de uso é
realizado,
associando o caso
Diagramas de Sequência

de uso com classes Diagramas de Colaboração Diagramas de Classe

e outros elementos
de projeto

 Requisitos   Analise e projeto 

 Diagrama de
Atividades

MDS - Bacalá
1. Analisar Arquitetura

2. Analisar Caso de Uso

3. Projetar Classes

4. Projetar Banco de Dados

Módulo de Vendas

Módulo de
Interface Gráfica Estoque

Negócio Socket

Dados
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 implementação

Implementação
Componentes
Documento da
arquitetura

Plano de Integração
Modelo de dados Documento da
arquitetura
 Planejar Integração Integrar Sistema
e Subsistemas
Integrador do
Sistema e
Subsistemas

Corrigir
Defeitos

Programador
Estruturar Modelo de Implementar Realizar Testes
Implementação Componentes de Unidade

Revisar
Revisor de Código Código Fonte
 Identificar quais componentes participam da iteração (colaboram
para os casos de uso da iteração)
F o r m u la r io C o n t r o la d o r Le it o r a C a r t a o M a q u in a C lie n t e Banc o
Saque C lie n t e D in h e ir o
: C lie n t e

in s e r e c a r t a o

in ic ia r s e s s a o ( d a d o s c a r t 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 r t a o , s e n h a )

v e r if 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 r a v a lo r
e n t r a v a lo r
v e r if 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 ar t a o

c a rt a o

s o lic it a e n t r e g a d in h e ir o
d in h e ir o
 Identificar quais pacotes participam da iteração (colaboram para
os casos de uso da iteração)

*
Applicação

* x
Negócio
Candidatos a Stubs
*
Middleware *

x *
Básico
 Definir os builds que serão gerados

a b
3

Aplicação
c d
2
Comunicação
e g
2 Stubs
f
1
Negócio

h i j
1
Dados
 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?

 Planejar Integração Integrar Sistema
e Subsistemas
Integrador do
Sistema e
Subsistemas

Corrigir
Defeitos

Programador
Estruturar Modelo de Implementar Realizar Testes
Implementação Componentes de Unidade

Revisar
Revisor de Código Código Fonte
 Modelo de Implementação

◦ Modelo de projeto gerado a partir da engenharia

reversa do código fonte do sistema
 Planejar Integração Integrar Sistema
e Subsistemas
Integrador do
Sistema e
Subsistemas

Corrigir
Defeitos

Programador
Estruturar Modelo de Implementar Realizar Testes
Implementação Componentes de Unidade

Revisar
Revisor de Código 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

 Planejar Integração Integrar Sistema
e Subsistemas
Integrador do
Sistema e
Subsistemas

Corrigir
Defeitos

Programador
Estruturar Modelo de Implementar Realizar Testes
Implementação Componentes de Unidade

Revisar
Revisor de Código 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

 Planejar Integração Integrar Sistema
e Subsistemas
Integrador do
Sistema e
Subsistemas

Corrigir
Defeitos

Programador
Estruturar Modelo de Implementar Realizar Testes
Implementação Componentes de Unidade

Revisar
Revisor de Código 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

 Planejar Integração Integrar Sistema
e Subsistemas
Integrador do
Sistema e
Subsistemas

Corrigir
Defeitos

Programador
Estruturar Modelo de Implementar Realizar Testes
Implementação Componentes de Unidade

Revisar
Revisor de Código 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
 Planejar Integração Integrar Sistema
e Subsistemas

Integrador do
Sistema e
Subsistemas

Corrigir
Defeitos

Programador
Estruturar Modelo de Implementar Realizar Testes
Implementação Componentes de Unidade

Revisar
Revisor de Código 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
 Disciplina de Implantação
Finalidade: Descrever as atividades que garantam que o produto de
software será disponibilizado a seus usuários finais.

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.
 Carlos Henrique M. da Silva
carloshenrique.85@globo.com

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