+

Aula 3 – Processos de
software
Rational Unified
Engenharia de Software Process
+
RUP - Histórico

 UP
– Processo Unificado (1990) – Jacobson, Booch e
Rumbaugh;
O RUP (2003), é um processo proprietário de
Engenharia de Software criado pela Rational
Software Corporation, adquirida pela IBM;
 Concepção foi baseada nas práticas de maior
retorno de investimento (ROI) do mercado.
+
RUP - Conceitos

O RUP é um modelo de processo moderno, derivado

de trabalhos sobra a UML e o Unified Software
Development Process.
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.

Objetivo: Assegurar a produção de software de alta

qualidade dentro de prazos e orçamentos previsíveis.
+
RUP - Conceitos

 Abordagem organizada em disciplinas para

atribuir tarefas e responsabilidades;
 Sobre as atividades:
 Descrição clara e precisa;
 Apresentam responsáveis;
 Determinados artefatos de entrada e saída;
 Determinadas dependências entre as atividades;
 Seguem modelo de ciclo de vida bem definido;
 Descrição sistemática de como podem ser executadas
com as ferramentas disponibilizadas (procedimentos)
 Preconizam o uso da linguagem UML.
+
RUP – Características

 Dirigido por casos

de uso;
 Centrado na
arquitetura;
 Iterativo
e
incremental;
 Focado em riscos.
+
RUP – Dirigido por caso de uso

 Processo compreendido do ponto de vista do

usuário;
O conj. de casos de uso deve definir e esgotar
toda a funcionalidade possível do sistema;
 Serão úteis para as atividades:
 Definiçãoe validação da arquitetura do sistema;
 Criação dos casos de teste;
 Planejamento das iterações;
 Base para a documentação do usuário.
+
RUP – Centrado na Arquitetura

A arquitetura, inicialmente, pode ser

compreendida como o conjunto de classes,
possivelmente agrupadas em componentes;
É um modelo que define a estrutura da
informação, suas possíveis operações e sua
organização em componentes ou camadas.
+
RUP – Iterativo e Incremental

 Desenvolvimento em ciclos de duração fixa;

 Cadaciclo contém um objetivo e produz um
incremento no design do sistema;
 Emcada iteração, todas as disciplinas
previstas sejam executadas com maior ou
menor intensidade;
A integração contínua reduz riscos, facilita
os testes e melhora o aprendizado da
equipe sobre o sistema.
+
RUP – Focado em Riscos

 Devido priorizações dos casos de uso mais

críticos;
 Essaabordagem (tratar primeiro os problemas
mais difíceis) tem sido um valor incorporado a
vários modelos de desenvolvimento modernos.
 Isto
garante maior aprendizado sobre o sistema,
decisões arquiteturais mais importantes e fazer
que riscos positivos ou negativos sejam
dominados o mais cedo possível.
+
RUP – Fases de
Desenvolvimento
1. Concepção (inception)
 Ênfase no escopo do sistema
2. Elaboração (elaboration)
 Ênfase na arquitetura
3. Construção (construction)
 Ênfase no desenvolvimento
4. Transição (deployment)
 Ênfase na implantação
+
RUP – Fase: Concepção

 Recomenda-se um período de duas semanas a dois

meses (dimensão do projeto);
 Abrangetarefas de comunicação com o cliente e
planejamento;
 Requisitos
são analisados da melhor forma possível,
em abrangência, e não profundidade;
 Estabelecimento de casos de uso:
 Obter casos de usos a partir de requisitos funcionais;
 Inicialmente análise de cenários e posteriormente
extrais os casos de uso, ou seja os requisitos;
 Trabalhar apenas com caso de uso, sendo eles única
expressão de requisitos
+
RUP – Fase: Elaboração

 Objetivos:
 Produzir uma arquitetura executável confiável
para o sistema;
 Desenvolver o modelo de requisitos até
completar pelo menos 80% dele;
 Desenvolver um projeto geral para a fase de
construção;
 Garantir que as ferramentas críticas, processos,
padrões e regras estejam disponíveis;
 Entender e eliminar os riscos de alta prioridade
do projeto.
+
RUP – Fase: Construção

 Objetivos:
 Descrever os requisitos que ainda faltam;
 Dar substância ao design do sistema;
 Garantir que o sistema atenda às necessidades dos
usuários e que ele se encaixe no contexto geral da
organização;
 Completar o desenvolvimento dos componentes e
testá-los, incluindo tanto o software quanto sua
documentação;
 Minimizar os custos de desenvolvimento pela
otimização dos recursos;
 Obter a qualidade adequada o mais rápido possível;
 Desenvolver versões úteis do sistema.
+
RUP – Fase: Transição

 Colocação do sistema em uso no ambiente

final;
 Atividades:
testes de aceitação e operação,
treinamento de usuários e transição de
dados;
 Apósa conclusão da fase de transição, o
sistema entra em evolução.
+
RUP – Blocos de Construção

Quem: um papel define um conj. de habilidades

para realizar determinadas atividades;
O quê: o produto do trabalho (work product)
podem ser diagramas, relatórios;
Como: uma atividade descreve uma unidade de
trabalho atribuída a um papel que produz
determinado conjunto de artefatos;
Quando: os workflows são grafos que definem
as dependências entre as atividades.
+
RUP - Papéis

 Cinco categorias principais:

 Analista
 Desenvolvedor
 Testador
 Gerente
 Outros
+
RUP - Disciplinas

 Seis disciplinas de projeto e três de suporte:

 Modelagem de negócio;
 Requisitos;
 Análisee design;
 Implementação;
 Teste;
 Implantação

 Gerenciamento de mudança e configuração;

 Gerenciamento de projeto;
 Ambiente.
+
RUP – Rational Unified Process

Diferentes ênfases de cada disciplina nas diferentes fases do

RUP
+
RUP – Disciplina:
Gerenciamento de Projeto
 Balancear objetivos que competem entre si, gerenciar
riscos e superar restrições com o objetivo de obter um
produto que atenda às necessidades dos clientes (que
pagam) e dos usuários finais;
 Indicarcomo planejar o projeto como um todo, como
planejar cada iteração individual, como gerenciar os
riscos do projeto e como monitorar o progresso;
 RUP não trata:
 Gerenciamento de pessoas, incluindo contratação e
treinamento;
 Gerenciamento de orçamento;
 Gerenciamento de contratos.
+
RUP – Disciplina:
Gerenciamento de Projeto
 Papéis:
 Gerente de projeto;
 Revisor de projeto.

 Artefatos:
 Caso de negócio;
 Plano de desenvolvimento de software;
 Plano de iteração;
 Avaliação da iteração;
 Ordem de serviço;
 Avaliação de status;
 Medidas de projeto.
+
RUP – Disciplina: Modelagem de
negócio
 Papéis:
 analistade processo de negócio;
 Designer de negócio;
 Interessados (stakeholders);
 Revisor de negócio

 Artefatos:
 Documento de visão de negócio;
 Modelo de caso de uso de negócio;
 Modelo de análise de negócio.
+
RUP – Disciplina: Requisitos

 Papéis:
 analista de sistemas;
 Especificador de requisitos ou especificador de casos de
uso;
 Arquiteto;
 Revisor de requisitos.

 Artefatos:
 Visãogeral do sistema;
 Modelo de caso de uso;
 Especificações suplementares.
+
RUP – Disciplina: Análise e
Design
 Papéis:
 Arquiteto de software;
 Designer.

 Artefatos:
 Modelode design;
 Documento de arquitetura de software.
+
RUP – Disciplina:
Implementação
 Papéis:
 Implementador;
 Integrador;
 Arquiteto de software;
 Revisor de código.

 Artefatos:
 Subsistema de implementação;
 Elementos de implementação;
 Plano de integração de implementação.
+
RUP – Disciplina: Teste
 Papéis:
 Gerente de teste;
 Analista de teste;
 Designer de teste;
 Testador.

 Artefatos:
 Plano de teste;
 Lista de ideias de teste;
 Casos de teste;
 Scripts de teste;
 Modelo de análise de carga;
 Log de testes;
 Resultados de testes.
+
RUP – Disciplina: Implantação

 Papéis:
 Gerente de implantação;
 Gerente de projeto;
 Redator técnico;
 Desenvolvedor de cursos;
 Artista gráfico;
 Testador;
 Implementador.

 Artefatos:
 Release – Versão final do software.
+
RUP – Disciplina:
Gerenciamento de Mudança e
Configuração
 Papéis:
 Gerente de configuração;
 Gerente de controle de mudança.

 Artefatos:
 Planode gerenciamento de configuração;
 Requisições de mudança.
+
RUP – Disciplina: Ambiente

 Papéis:
 Engenheiro de processo;
 Especialista em ferramentas;
 Administrador de sistema;
 Redator técnico.

 Artefatos:
 Caso de desenvolvimento: versão do processo
geral.