Rational Unified Process (RUP)

Carlos Henrique M. da [email protected]

mailto:[email protected]

1. Histórico e Conceitos

2. Melhores práticas

3. Fases

4. Disciplinas

O RUP, Processo Unificado Racional é um processo proprietário deEngenharia de software criado pela Rational Software Corporation,adquirida pela IBM, ganhando um novo nome IRUP e tornando-seuma brand na área de Software, fornecendo técnicas a seremseguidas pelos membros da equipe de desenvolvimento de softwarecom o objetivo de aumentar a sua produtividade no processo dedesenvolvimento.

O RUP usa a abordagem da orientação a objetos em sua concepção eé projetado e documentado utilizando a notação UML (UnifiedModeling Language) para ilustrar os processos em ação. Utilizatécnicas e práticas aprovadas comercialmente.

O RUP é, por si só, um produto de software. É modular eautomatizado, e toda a sua metodologia é apoiada por diversasferramentas de desenvolvimento integradas e vendidas pela IBMatravés de seus "Rational Suites".

Métodos concorrentes no campo da engenharia de software incluemo "Cleanroom" (considerado pesado) e os Métodos Ágeis (leves) comoa Programação Extrema (XP), Scrum, FDD (Desenvolvimento Guiadopor Funcionalidades) entre outros.

Objetivo é assegurar a produção de software de alta qualidadedentro de prazos e orçamentos previsíveis (Kruchten 2003, pág. 14)

O RUP define perfeitamente quem é responsável pelo que, como ascoisas deverão ser feitas e quando devem ser realizadas,descrevendo todas as metas de desenvolvimento especificamentepara que sejam alcançadas.

Oferece uma abordagem organizada em disciplinas para atribuirtarefas e responsabilidades dentro de uma organização dedesenvolvimento.

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 IterativamenteDesenvolver iterativamente significa desenvolver em ciclos. Cadaciclo é contém um objetivo que deve ser alcançado (lançamento deum 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 maisfacilidade;

Integração progressiva (quase continua) de elementos aosoftware, ocasionando uma melhora no descobrimento eendereçamento de riscos;

Desenvolvimento iterativo provê aos gerentes maneiras defazer mudanças táticas aos produtos; etc.

Gestão de Requisitos

O gerenciamento de recursos acarreta um melhor controle sobreprojetos 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 deuso 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 naprogramação orientada a objetos.

O RUP oferece uma forma sistemática para construir este tipo desistema, focando-se em produzir uma arquitetura executável nasfases iniciais do projeto, ou seja, antes de comprometer recursos emlarga escala.

Estes componentes são normalmente incluídos em infraestruturasexistentes como o CORBA e o COM (Modelo de Componentes deObjetos).

Uso de Software de Modelos Visuais

A modelagem visual permite melhor entender não só a concepção e acomplexidade do sistema, mas também “dimensionar” (no sentido dequal a forma do sistema), além de facilitar a identificação e soluçãode problemas.

Verificação da qualidade do softwareNão assegurar a qualidade do software é a falha mais comum emtodos os projetos de sistemas computacionais. Normalmente pensa-se em qualidade de software após o término dos projetos, ou aqualidade é responsabilidade de uma equipe diferente da equipe dedesenvolvimento.

O RUP não toma a qualidade como responsabilidade de apenas umapessoa ou grupo, mas como uma responsabilidade de todos osintegrantes do projeto.

A qualidade é focada especialmente em duas áreas: Qualidade de produto: Sendo desenvolvido (software ou sistema) etodos 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 monitorarmudanças. Como uma pequena mudança pode afetar aplicações deformas 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 umprogramador que as mudanças efetuadas noutro sistema nãoafetarão o seu sistema.

Fases de Desenvolvimento

Até agora estas linhas de guia são gerais, a serem aderidas aopercorrer do ciclo de vida de um projeto. As fases indicam a ênfaseque é dada no projeto em um dado instante. Para capturar adimensão do tempo de um projeto, o RUP divide o projeto emquatro 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. Pessoas2. Projeto3. Produto4. Processo

As fases são compostas de iterações. As iterações são janelas detempo; as iterações possuem prazo definido enquanto as fases sãoobjetivas.

Todas as fases geram artefatos. Estes serão utilizados nas próximasfases e documentam o projeto, além depermitir melhor acompanhamento.

Fase de Concepção

Esta fase do RUP abrange as tarefas de comunicação com o cliente eplanejamento.

É feito um plano de projeto avaliando os possíveis riscos, asestimativas 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çãodo escopo do projeto, onde são examinados os objetivos para sedecidir 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 dodomínio do problema, revisando os riscos que o projeto pode sofrere a arquitetura do projeto começa a ter sua forma básica.

Indagações como “O plano do projeto é confiável?”, “Os custos sãoadmissí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 desoftware, com foco no desenvolvimento de componentes e outrosrecursos 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-odisponível e compreendido pelo usuário final.

As atividades desta fase incluem o treinamento dos usuários finais etambém a realização de testes da versão beta do sistema visandogarantir que o mesmo possua o nível adequado de qualidade.

DisciplinasAs disciplinas descrevem o aspecto estático do processo, como ele édescrito em termos de componentes, disciplinas, atividades, fluxosde 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 daorganização na qual o sistema será implantado e como usar estavisão como uma base para descrever o processo, papéis eresponsabilidades.

O objetivo de modelagem de negócios é, primeiramente, estabeleceruma melhor compreensão e canal de comunicação entre engenhariade negócios e engenharia de software. Compreender o negóciosignifica que os engenheiros de software devem compreender aestrutura e a dinâmica da empresa alvo (o cliente), os atuaisproblemas 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 queos produtos funcionam no âmbito do sistema a ser construído efornecem 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 serrealizado. 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 requisitosfuncionais.

Engenharia - Disciplina de Implementação

Os efeitos da implementação são:

Para definir a organização do código, em termos de subsistemasde 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 implementadoresindividuais (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 corretamenteimplementados Identificar e garantir que os defeitos são abordados antes daimplantação do software Garantir que todos os defeitos são corrigidos, reanalisados efechados

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 oprocesso para um projeto.

Ele descreve as atividades necessárias para desenvolver as diretrizesde apoio a um projeto.

A proposta das atividades de ambiente é prover à organização dedesenvolvimento de software os processos e as ferramentas quedarão suporte à equipe de desenvolvimento.

Se os usuários do RUP não entendem que o RUP é um framework deprocesso, 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 abrangetrês gerenciamentos específicos: de configuração, de solicitações demudança, e de status e medição.

A Rational também tem um produto para manter as solicitações demudança chamado ClearQuest.

Apoio/Suporte - Disciplina de Gerência de Projeto

Esta disciplina concentra-se principalmente sobre os aspectosimportantes de um processo de desenvolvimento iterativo:

Gestão de riscos; Planejamento de um projeto iterativo através dociclo de vida e para uma iteração particular; E o processo deacompanhamento de um projeto iterativo, métricas. No entanto, estadisciplina do RUP não tenta cobrir todos os aspectos dogerenciamento de projetos. Por exemplo, não abrange questõescomo:

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 dedesenvolvimento de software, ele representa uma nova geração deprocessos genéricos. A mais importante inovação é a separação defases e workflows, e o reconhecimento de que a implantação desoftware no ambiente do usuário é parte do processo. As fases sãodinâmicas e tem objetivos. Os workflows são estáticos e constituematividades técnicas que não estão associadas a uma única fase, maspodem ser utilizados ao longo do desenvolvimento para atingir osobjetivos 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 “coredisciplines”. Dentro do ciclo de desenvolvimento de softwarepodemos dizer que essa é sem dúvida a disciplina menos praticada.

RUP não define esta como uma disciplina obrigatória, mas recomendafortemente que ela seja executada especialmente para empresas queestão iniciando um novo negócio e não possuam uma claramodelagem do negócio.

Modelagem de NegóciosFinalidades:

Entender os problemas da organização identificando aspossíveis melhorias;

Avaliar o impacto de mudanças na organização;

Assegurar que os clientes, usuários, desenvolvedores e outrosparceiros tenham uma compreensão comum da organização;

Gerar conteúdo para a fase de requisitos do sistema quesuportará a organização e seus processos;

Entender como o software se ajustará à organização.

Modelagem de NegóciosPapéis e Artefatos

A importância da definição de papéisnão é somente para melhorardivisão do trabalho, mas principalmente para que hajana equiperesponsabilidades definidas para cada atividade realizada, fazendo,assim,com que os membros tenham que cumprir direitinho as suastarefas e que respondam por elas.

Gerente de Projeto

Analista de Processos de Negócio (Dentro da disciplina deModelagem 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 osprojetos 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 astarefas necessárias, as delegava aos membros da equipe e ficavapressionando cada um para cumprir os prazos.

Hoje, essa realidade mudou. O gerente de projeto é um indivíduoextremamente participativo: realiza parcerias com os membros daequipe, estimula e valoriza as soluções encontradas e conduz oandamento do projeto, protegendo a equipe de distrações eorganizando cronogramas, defende os interesses do time e realiza acomunicação com o cliente.


Analista de Processos de Negócio


Designer 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 devefazer e permite que desenvolvedores e clientes concordem com essadescrição. Para conseguir isso, obter, organizar e funcionalidadedocumento desejado e restrições; acompanhar e documentarcompromissos e decisões.

Uma visão do documento é criada, e necessidades das partesinteressadas 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

Materiais/wf_req.gif

ATIVIDADES

ARTEFATOS

ENGENHARIA DE REQUISITOSÉ fundamental para o desenvolvimento de um software acompreensão dos requisitos. Se a análise e a especificação dasfunçõ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 umdocumento 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 RequisitosO processo de Engenharia de Requisitos é um conjunto de atividadesa serem seguidas para desenvolver um documento de requisitos.

Sommerville sugere um modelo de atividades que pode descrever amaioria dos processos de Engenharia de Requisitos.

As atividades nem sempre ocorrem sequencialmente, em geralrealizam 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 deelicitação de requisitos:

Entendimento do domínio da aplicação – entendes-e a área na qual osistema 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 dosistema 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 seremprovidas pelo sistema à realização do trabalho e aos interesses decada um dos stakeholders; os trabalhos a serem apoiados pelosistema e; o papel de eventuais sistemas existentes na execução econdução dos processos de trabalho.

Análise e Negociação dos Requisitos

Depois da elicitação de requisitos todo esse conhecimento adquirido pelosstakeholders precisa ser representado através de notações diversas. Essasrepresentações precisam estar sempre consistentes.

Negociação de requisitos é uma atividade extremamente complexa, ter umentendimento global de todos os objetivos, soluções e interação entre eles éuma tarefa muito difícil de executar. Assim existem diferentes métodos etécnicas de negociação.

Robinson estabelece uma infraestrutura para modelar o processo denegociaçã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 documentadospara que possam servir de base para o resto do processo.

Administrar o volume de informações que são gerados pelo processo deengenharia de requisitos é um dos principais problemas que se enfrenta nadocumentação de requisitos. Para se tornar um pouco mais fácil aadministração desse documento usa-se uma notação gráfica que diminui otamanho 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 naliteratura:

Modelo 1 – Roger S. Pressman

Modelo 2 – RUP (Rational Unified Process)

Modelo 3 – Wilson de Pádua Filho

Validação dos RequisitosEsta atividade acontece no final da especificação de requisitos e seuobjetivo é verificar se a documentação dos requisitos estaconsistente 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 aespecificação de requisitos está correta, pois não existe uma formapara isso.

GERENCIAMENTO DE REQUISITOSGerenciamento de requisitos trata-se de um modelo sistemático praidentificar, organizar e documentar os requisitos do sistema,estabelecer e manter acordo entre o cliente e a equipe do projeto nosrequisitos 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 doprojeto.

GERENCIAMENTO DE REQUISITOSExistem requisitos funcionais e não-funcionais. Exemplos:

Funcional: o usuário deve selecionar a opção de inclusão paracadastrar um novo aluno no banco de dados.

Não-funcional: o sistema deve ser compatível com asplataformas Windows e Linux.

Não-funcional: o sistema deverá ser desenvolvido em Java.

É natural que alguns requisitos possam não ser definidos corretamente noiní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 oscasos de uso em mãos.

Queremos agora gerar um primeiromodelo do sistema a partir dos casos deuso.

Este é chamado de modelo de análise.

Requisitos Análise Projeto

Vai proporcionar um método que permita quecriemos um modelo de classes do sistema apartir dos casos de uso

Trará a resposta para a pergunta:

Quais classes preciso para implementar estescasos 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 asrealizações de casos de uso

Pode ser particionado em dois modelos

Modelo de Analise

Modelo de Projeto

Diagramas de Classe Diagramas 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 ocaso de uso érealizado,associando o casode uso com classese outros elementosde 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 conceitosdo Banco de Dados

Definir os tipos de dados mais adequados parao 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 deimplementaçã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 implementadoresindividuais (ou equipes) ao sistema executável

Modelo de projeto

Modelo de dados

Implementação

Documento daarquitetura

Modelo de implementação

Componentes

Plano de Integração

Documento daarquitetura

Estruturar Modelo deImplementação

Revisor de Código

Programador

Integrador doSistema eSubsistemas

Planejar Integração Integrar Sistemae Subsistemas

Implementar

Componentes

CorrigirDefeitos

Realizar Testes

de Unidade

RevisarCódigo Fonte

Identificar quais componentes participam da iteração (colaborampara 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 paraos 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 decriação de stubs?

A ordem de integração facilita a detecção de erros?

Estruturar Modelo de

Implementação

Revisor de Código

Programador



Implementar

Componentes

CorrigirDefeitos

Realizar Testes

de Unidade


Modelo de Implementação

Modelo de projeto gerado a partir da engenharia reversa do código fonte do sistema


Implementação

Revisor de Código

Programador



ImplementarComponentes

CorrigirDefeitos

Realizar Testesde Unidade


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


Implementação

Revisor de Código

Programador




CorrigirDefeitos



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



Implementação

Revisor de Código

Programador




CorrigirDefeitos



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


Implementação

Revisor de Código

Programador




CorrigirDefeitos



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


Implementação

Revisor de Código

Programador




CorrigirDefeitos



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


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 [email protected]

mailto:[email protected]

Rational Unified Process (RUP)

Technology

Transcript of Rational Unified Process (RUP)