RUP para Concursos

O RUP é um produto da IBM em formato de um framework de processos

adaptável. Não devemos pegar este framework e aplicar tudo o que está

escrito. É necessário entendê-lo e configurar a estrutura do RUP para adaptá-lo

à realidade da sua organização. RUP É um modelo prescritivo (diz como as

coisas devem ser feitas) que fornece atividades, artefatos e guias que

geralmente recomendam a utilização de outros produtos da IBM e da

linguagem de modelagem UML. Em provas o RUP é tratado como processo de

desenvolvimento ou metodologia.

Características do RUP

Iterativo e Incremenntal

O ciclo de vida do produto é divido em iterações, que são passagens

sequenciais pelas disciplinas de engenharia de software. O problema total a ser

resolvido é dividido em partes menores e a cada incremento uma parte

acabada do software é entregue.

Guiado por Casos de Uso

Os casos de uso são utilizados por todas as partes interessadas, inclusive os

stakeholders. É o documento que conecta todas as fases e disciplinas do RUP

de uma forma ou de outra.

Centrado na Arquitetura

É a macroestrutura que organiza os principais elementos do seu sistema, como

classes, interfaces e componentes. A arquitetura evolui de acordo com as

principais necessidades dos sistema. Essas necessidades estão maepadas

nos casos de uso.

Orientado a Objetos

Os componentes são baseados em objetos e colaboram entre si para

implementar (realizar) os casos de uso.

Planejado por Riscos

Os riscos são analisados a todo tempo e aqueles que MAIS CRÍTICOS são

tratados prioritariamente. Os casos de uso arquiteturalmente significativos (os

mais difíceis, nebulósos, críticos, arriscados, etc) são os primeiros a serem

implementados.

Gráfico das Baleias

O RUP é compostos por 4 fases e 9 disciplinas.

No gráfico você percebe dois eixos. O eixo horizontal, a primeira dimensão ou

a dimensão dinâmica representa o passar do tempo ao longo do projeto.

Mostra os aspectos do ciclo de vida do processo a medida que o projeto se

desenvolve.

Possui as 4 fases (Iniciação, Elaboração, Construção e Transição). Cada fase

possui várias iterações e dá ênfase em determinadas disciplinas, cada

disciplina possui mais importância em determinada fase e menor importância

em outra fase. A iteração de uma fase passa por todas as disciplinas.

Ao final de cada fase existe um marco ou milestone. É um ponto do projeto e

um determinado conjunto de artefatos que foi alcançado e estabilizado. Cada

fase possui o seu marco. Determina o fim da fase.

O eixo vertical, segunda dimensão ou eixo estático, é onde são representadas

as disciplinas (agrupamento das atividades de engenharia de software, por

área de interesse ou natureza das atividades). É estático porque as atividades

a serem executadas são sempre as mesmas, não variam de acordo com o

tempo. Um determinada disciplina possui as mesmas atividades em todas as

fases. Assim, o eixo estático não considera a passagem do tempo. O que varia

é a ênfase em uma disciplina ou em outra de acordo com o tempo.

As disciplinas possuem atividades, papéis, artefatos e produtos de trabalho.

São 9 disciplinas no total. 6 de engenharia (Modelagem de Negócios,

Requisitos, Análise e Design, Implementação, Teste e Implantação) e 3 de

suporte (Gerenciamento de Configuração e Mudança, Gerenciamento de

Projeto e Ambiente)

No gráfico, quanto maior a área que uma disciplina ocupa em determinada

fase, maior a ênfase naquela disciplina durante a fase. Todas as disciplinas são

consideradas em todas as fases, mas algumas possuem maior atividade e

outras possuem menor ou nenhuma atividade em determinado momento.

O RUP tem duas dimensões.

A primeira dimensão, eixo horizontal, representa o aspecto dinâmico do

processo.

Expresso em fases, marcos e iterações.

A segunda dimensão, eixo vertical, representa o aspecto estático do processo.

Expresso em componentes, disciplinas, atividades, artefatos, papéis e etc.

RUP para Concursos - Parte 2 - Metodologia e Conceitos Chave

Metodologia

É composta por um Processo de Desenvolvimento que é configurado

especificamente para a sua organização. É composta por um conjunto de

métodos e práticas bem definidos e que possuem responsáveis (papéis),

entradas, saídas e ordem de precedência. Inclui ferramentas, tecnologias,

pessoas, padrões e guias.

Ao instânciar um processo de desenvolvimento baseado no RUP, o que se está

procurando é definir quem faz (papéis), o que é feito (produtos de trabalho) ,

como é feito (descrições das tarefas) e quando é feito (fluxos de trabalho). Nas

disciplinas existem papéis que executam determinada tarefa ou atividade que

resulta em um produto de trabalho ou artefato. Um exemplo seria a disciplina

de Requisitos possui o papel Analista de Sistemas que deve executar a tarefa

Estruturar Modelo de Caso de Uso e o produto de trabalho gerado será o

Modelo de Caso de Uso.

Você terá uma metodologia baseada no RUP e não a metodologia RUP em sí.

A organização deve pegar o RUP e adaptá-lo de acordo com as necessidades

e assim, criar o seu próprio processo de desenvolvimento de software.

A metodologia conta com alguns componentes: Modelos, padrões, guias,

equipes treinadas, linguagem padrão (UML) e ferramentas de automação.

Benefícios da Metodologia embasada no RUP:

Qualidade de Software através da utilização das melhores práticas de

mercado, que já foram testadas e comprovadas.

Maior produtividade e Previsibilidade porque as equipes seguem um processo

definido, o que evita conflitos dentro do projeto. As pessoas já sabem quem faz

qual atividade e quando fazer.

As características acima, o controle de riscos e a disciplina de gerência de

projetos do RUP levam a um Maior controle sobre custos e prazos.

Conceitos Chave do RUP

As 4 Fases do RUP

São as etapas dos projeto de desenvolvimento com base no RUP. (1º eixo,

Eixo Dinâmico do Gráfico das Baleias). Cada fase termina com um marco.

Concepção / Iniciação

Determinar o escopo do projeto para que seja possível estimar custos e riscos

do projeto. É gerado um macro-planejamento. Estima-se o tamanho do projeto,

os custos e os riscos. São definidos os objetivos que a organização pretende

alcançar com o projeto. Todas as partes interessadas devem entender os

objetivos a serem alcançados.

Elaboração

Assegura que os principais riscos foram diminuídos e uma arquitetura estável

foi definida. Dentre os casos de uso, que foram definidos na fase anteior,

aqueles mais arriscados, importantes e complexos são identificados e

implementados para garantir que a arquitetura está adequada. Isso já reduz o

risco do projeto. O marco é a aquitetura do projeto estabilizada.

Construção

Desenvolver o produto de forma iterativa e incremental para a Transição. 20%

dos casos de uso foram detalhados e implementados até a fase de Elaboração.

Aqui os outros casos de uso são implementados. Nessa fases as equipes

trabalham muito em paralelo e com velocidade. O marco da fase é o build

estabilizado do sistema ou a capacidade operacional inicial. O produto deve ser

capaz de ser operado.

Transição

Disponibilizar o software para o usuário final. Assegurar que o sistema esteja

disponível e funcionando corretamente. Inclui documentação do sistema, guias

do usuário e etc. O marco é o lançamento do produto.

As fases não são idênticas em termos de esforço e tempo gasto. Abaixo estão

alguns números mágicos da metodologia.

Iniciação Elaboração Construção Transição

Esforço ~5 % 20 % 65 % 10%

Programação (Cronograma) 10 % 30 % 50 % 10%

É possível ver que a fase Construção é a que consome maior tempo (50%) e

maior esforço (65%).

Uma passada pelas quatro fases é chamada de Ciclo de Desenvolvimento e

gera uma primeira versão do seu software, o que seria a versão 1.0. Uma

próxima versão, de evolução do software, seria a versão 2.0. Essa segunda

parte é considerada um novo ciclo e é conhecida como Ciclo de Evolução.

Durante o Ciclo de Evolução a ênfase nas fases não é a mesma do Ciclo de

Desenvolvimento. Na maioria dos casos, os riscos já são conhecidos e

arquitetura já está estabilizada, então, a fase de elaboração, por exemplo, será

menor.

Iterações

"Uma sequência distinta de atividades que resulta em um release do seu

produto". Uma iteração é uma passada pelas 6 disciplinas de ENGENHARIA do

seu projeto. As iterações podem ser consideradas como mini-projetos em

cascata.

As 6 disciplinas de engenharia são: Modelagem de Negócios, Requisitos,

Análise e Design, Implementação, Teste e Implantação.

A cada iteração as atividades de cada disciplina são executadas e no final é

gerado um produto de trabalho (release), que é um incremento no sistema.

Pode ser um release interno (para a equipe ou usuários específicos) ou um

release externo (para os clientes). Para que o release seja liberado, é perciso

estar estabilizado de alguma forma. Para isso é criada uma baseline. A

baseline é o estado estável e aprovado que libera o release.

Cada fase possui várias iterações. O que muda de uma fase/iteração para

outra é a enfase que é dada nas disciplinas. Durante a passagem por uma

disciplina pode não haver necessidade de executar nenhuma atividade de uma

disciplina específica. Isso acontence principalmente no início e no fim do

projeto.

Disciplinas

Conjunto de atividades (fluxo de trabalho) relacionadas a uma área de

interesse do projeto para geração de resultados. As disciplinas do RUP

lembram as fases do modelo em cascata, porque são as atividades técnicas

que são executadas durante o projeto. Detalham como executar as atividades,

quem executa e quais produtos de trabalho são gerados após a execução das

atividades.

Algumas disciplinas estão associadas a conjuntos específicos de modelos e os

modelos são conjuntos de artefados. Cada disciplina possui seu próprio fluxo

de trabalho, que é um diagrama de atividades da linguagem UML.

Disciplinas de Engenharia

Modelagem de Negócios

Requisitos

Análise e Projeto

Implementação

Testes

Implantação

Disciplinas de Suporte

Gerenciamento de Projetos

Gerenciamento de Configuração e Mudanças

Ambiente

M-RAITIGGA

Papéis

Definem o comportamento e as responsabilidades em um processo. Dentro de

uma disciplina, os responsáveis por executar as atividades são os papéis.

Exemplos de papéis são: programador, testador, gerente de projeto, arquiteto e

etc.

No final das contas, os papéis acabam associados a um ser humano, mas a

definição de um papel trata de um comportamento e de um conjunto de

responsabilidades. Uma pessoa pode executar um, nenhum ou vários papéis.

Tarefas ou Atividades

Uma unidade de trabalho desempenhada por um papel. Algo que um papel faz

e produz um resultado dentro do contexto de uma disciplina. São compostas

por: finalidade, passos, entradas e saídas, papel responsável, além de guias e

padrões para auxiliar a execução.

Produtos de Trabalho

São o resultado de um processo de trabalho utilizados como entradas e/ou

saídas na execução das atividades. São divididos em artefatos (termo

genérico), entregáveis (os que são entregados aos clientes) e os resultados

(outcomes), que são produtos intangíveis, representam o alcance de algum

objetivo. No geral, produtos de trabalho são chamados de artefatos.

Podem ser: modelos, documentos, código fonte, executáveis, etc

Resumindo: Papéis executam Tarefas que geram Artefatos.

Exemplo: O Especificados de Requisitos (papel) executa Atividade chamada

Detalhar Caso de Uso e gera um artefato, que é o próprio Caso de Uso.

Um ciclo de vida de desenvolvimento no RUP é a passagem pelas quatros

fases: Iniciação, Elaboração, Construção e Transição. Cada fase possui seus

objetivos próprios e são delimitadas por marcos. Quando uma fase é executada

e seus objetivos são alcançados, o marco é alcançado. Cada fase pode ter N

iterações, que são as passadas sequenciais pelas 6 disciplinas de engenharia

do projeto. Dentro das disciplinas existem os papéis que executam as

atividades e geram artefatos.

RUP para Concursos - Parte 3 - As 6 Melhores Práticas do RUP

Desenvolvimento Iterativo

É uma estratégia de resolução de problemas. Percorre-se várias vezes as

disciplinas de engenharia durante o ciclo de vida do projeto. Cada iteração é

uma passada pelas disciplinas e a cada uma delas a equipe aprende e ganha

compreensão a respeito do projeto, dos requisitos e dos componentes. A

arquitetura se torna mais robusta a cada incremento. É uma maneira mais

flexível de desenvolvimento e impede que o risco seja acumulado para o final

do projeto. O risco diminui com o tempo porque é percebido, avaliado e

mitigado a cada iteração.

Lida com mudanças com mais facilidade. A cada incremento existe a chance

de se verificar as mudanças nos requisitos e é possível se adaptar e replanejar

o projeto. O replanejamento acontece a cada iteração.

Diminui os riscos porque são avaliados mais cedo. A cada iteração é possível

integrar o código, verificar as interfaces e os usuário também poderão avaliar o

que foi produzido para dizer se o caminho está correto.

Melhora a qualidade do software e a equipe aprende e melhora porque a cada

iteração os usuários avaliam o que foi feito, passam o feedback e é possível

corrigir os rumos do projeto. O conhecimento do negócio aumenta de forma

mais precisa a cada interação com os usuários.

Aumenta o reuso porque é mais fácil pensar em reutilizar um componente que

já está parcialmente ou totalmente implementado do que pensar em todos os

componentes de forma antecipada. É quase impossível prever estes

componentes apenas com os casos de uso especificados.

As iterações incorporam um conjunto quase sequencial das atividades. Só não

é sequencial de fato porque algumas disciplinas podem não ser executadas em

determinada fase.

Gerenciamento de Requisitos

Requisitos mal especificados, mal compreendidos e mal documentados geram

problemas para TODO o projeto. Requisito é a necessidade e o propósito do

seu cliente. É uma condição ou restrição com a qual o sistema deverá estar em

conformidade. Não adianta implementar um requisito errado da melhor forma

do mundo, porque isso não atende às necessidades do cliente. A forma como o

requisito é entendido nem sempre é o que o cliente precisa e deseja.

Normalmente os requisitos se resumem a funcionais e não funcionais.

O RUP diz que o documento de requisitos deve ser feito de maneira clara. E o

Gerenciamento de requisitos é uma abordagem sistemática para localizar,

documentar, organizar e controlar os requisitos variáveis em um sistema. Além

disso é preciso manter a integridade dos requisitos através da rastreabilidade.

Os requisitos possuem vários problemas: nem sempre são claros e podem vir

de várias fontes diferentes. Cada fonte tem a sua visão e a sua prioridade.

Duas fontes diferentes podem ter visões conflitantes. Além disso, existe uma

interdependência entre requisitos diversos e os documentos devem tratar isso

de forma consistente.

Cada requisito é diferente. A complexidade muda e a importância também.

Alguns são simples e pouco importantes e outros podem trazer problemas para

todo o projeto. É preciso identificar essa complexidade e tratá-los no momento

certo do ciclo de vida do projeto.

Existem várias partes interessadas e pode haver conflito de interesses entre as

essas partes. Além disso, o número de requisitos pode se tornar tão grande

que fica impossível gerenciá-los.

Os requisitos são alterados a todo tempo.

Mudanças de requisitos identificadas tardiamente são as principais causas de

insucesso nos projetos de desenvolvimento de software.

Como gerenciar essas dificuldades? Analisando o problema.

Entenda o "problema por trás do problema".

Estabeleça um vocabulário comum (UML e Glossário).

Proponha soluções em alto nível: nível de análise e não em nível de projeto.

Entenda a necessidade das partes interessadas e evite o desenvolvimento

customizado

Todos querem algo. Determine qual é a melhor fonte dos requisitos, a fonte

que realmente agrega valor. Utilize técnicas de elicitação de requisitos. Faça

acordos, balancie prioridades, ou seja, negocie com as partes interessadas

para saber o que é crítico, o que é importante, o que é desejável e dispensável.

Alguns requisitos são fundamentais para entrada em produção. Outros não.

Defina o sistema.

Defina o que o sistema deve fazer, em termos gerais, utilizando linguagem

natural e linguagem gráfica (UML).

Gerencie o escopo do sistema

Tudo o que está no Modelo de Casos de Uso faz parte do escopo do sistema.

O que está dentro? e fora? Estabeleça as prioridades para selecionar o que

entra e o que sai.

Gerencie os requisitos variáveis

Garanta que os requisitos tenham uma estrutura que os tornem facilmente

atualizáveis (utilize referências em seus documentos de casos de uso).

Rastreie as mudanças em seus requisitos. Toda vez que uma mudança afetar

um requisito ela deve ser analisada, o impacto e os riscos devem ser

considerados e só poderá ser executada se aprovada após a análise.

Mudanças sem análise não devem ser implementadas.

Os Casos de Uso guiam o desenvolvimento

O RUP recomenda a utilização de Casos de Uso como método para a

organização dos requisitos funcionais. Assim você consegue organizar uma

visão de como o usuário enxerga o sistema.

Os casos de uso definem um conjunto de cenários e cada cenário descreve o

comportamento do sistema em uma sequência de ações. Esses cenários

devem produzir um resultado de sucesso ou de erro de valor observável para

um ator.

Atores são entidades externas que se relacionam com o seu sistema. Podem

ser pessoas, outros sistemas e etc.

Quem utiliza os casos de uso? Os clientes utilizam para compreenção do

comportamente do sistema e para aprovação do funcionamento antes da

implementação. Os arquitetos analisam os casos de uso para definir a

arquitetura do sistema logo na fase de elaboração. Os analistas, projetistas e

programadores para entender o comportamento do sistema, refinar e

implementar. Os casos de testes também são gerados a partir dos casos de

uso. O gerente utiliza para acompanhar o progresso do projeto e por aí vai. Por

isso se diz que o RUP é guiado por Casos de Uso

Arquitetura de Componentes

A arquitetura é a estrutura organizacional do software. Segundo o RUP é "a

sua organização ou estrutura de componentes significativos que interagem

através de interfaces". A arquitetura de um sistema reflete as grandes decisões

a respeito da implementação. Diz em quantas camadas o sistema é feito, quais

frameworks são utilizados, quais padrões de projeto foram implementados e

coisas do tipo. E o RUP dá grande ênfase à arquitetura.

Segundo o RUP a arquitetura do software inclui: As decisões significativas

sobre a organização de um sistema. A seleção dos elementos estruturadores e

suas intefaces, a especificação dos elementos do sistema e como eles

colaboram entre si.

A arquitetura não se preocupa apenas com estrutura e comportamento, mas

também com funcionlidades, desempenho, segurança, reuso,

manutenibilidade, decisões técnológicas e econômicas. Por isso os requisitos

não funcionais, podem influenciar fortemente na decisão da arquitetura.

O que é um Componente?

É uma parte independente do seu sistema. Grupos de código coesos com

interfaces e comportamentos bem definidos. Possui forte encapsulamento de

conteúdo. Pode ser substituído por outro. Os componentes se comunicam

através de suas interfaces visíveis e um nunca conhece o comportamenteo

interno do outro.

Vantagens

Permite reuso em grande escala. Por serem independentes e coesos, podem

ser usados diversas vezes e em sistemas diferentes. O caso do Hibernate é

clássico: um componente para mapeamento OO-Relacional que é utilizado em

praticamente todos os sistemas de software web em java atualmente.

Bom gerenciamento da complexidade do projeto e mantém a integridade do

sistema. A separação em componentes permite que os problemas sejam

tratados de forma separada, já que eles são isolados. Isso identifica, isola,

projeta, desenvolve e testa as partes bem formadas do sistema em separado.

É possível utilizar componentes de prateleiras disponíveis no mercado.

Visões Arquiteturais

No RUP a arquitetura é representada por uma série de visões de arquitetura

diferentes. São perpectivas diferentes da arquitetura. Conhecido como modelo

de visão 4 + 1 porque são 5 visões disponíveis. Seria como a construção de

uma casa, ondem existem vários projetos diferentes. Um arquitetônico, um de

instalações elétricas, um de hiráulica e etc.

Visão Lógica ou Visão de Projeto descreve as principais classes no projeto do

sistema. Define as classes de projeto mais importantes, a organização em

pacotes e subsistemas, e a organização destes pacotes em camadas. É uma

das principais visões e é obrigatória. Os diagramas de classes, sequencia e

pacotes aparecem muito nesta visão.

Visão de Implementação contém a organização em termos de módulos,

pacotes e camadas. É uma visão opcional que entra nos detalhes da Visão

Lógica. Descreve o código da sua aplicação. Tudo o que foi gerado a partir do

projeto. Visão mais detalhada do projeto do sistema.

Visão de Processos descreve o ascpecto simultâneo do sistema. As tarefas

(processos e threads) que são concorrentes devem ser definidas nessa visão.

Só deve ser usado caso o sistema possua alto grau de paralelismo. Por isso é

opcional.

Visão de Implantação descreve como serão as configurações das instalações

físicas do sistema. Contém a descrição dos vários nós físicos do sistema e a

aloção de taréfas atribuídas a eles. É uma visão opcional, que pode ser usada

quando o sistema for distriuído.

Visão de Caso de Uso é uma visão externa, o ponto de vista do cliente a

respeito da perspectiva funcional. Contém os casos de uso e cenários que

abrangem comportamentos significativos em termos de arquitetura, classes, ou

riscos. É uma visão obrigatória do documento de arquitetura.

Modelagem Visual (UML)

Fazer uso de notação gráfica para exibir o projeto do software. A linguagem

gráfica permite que o nível de abstração seja aumentando, escondendo

detalhes e faciliando a comunicação com os clientes. Um usuário não

consegue entender o código e a linguagem escrita é muito ambígua para isso.

Essa notação visual também adiciona precisão à captura dos requisitos. Como

a ambiguidade é reduzida, acontece uma melhora na comunicação da equipe.

O RUP determina o uso da UML (Unified Modeling Language)

UML é uma notação padrão para modelagem de software. Oferece diferentes

perspectivas de um problema: estática, dinânima, colaborativa e etc. Ajuda a

manter o projeto (os diagramas) e o código consistentes.

Os artefatos UML possuem suporte das ferramentas automatizadas

recomendadas pelo RUP para ajuda na produtividade da equipe.

Verificação da Qualidade

Qualidade não é algo pontual, não deve ser verificada apenas no fim ou em

pontos específicos, mas em todo o seu projeto de forma contínua. "A

característica de ter demonstrado a realização de um produto que atende ou

excede os requisitos acordados, conforme avaliado por medidas e critérios

acordados".

Você deve estabelecer os critérios de qualidade anteriormente, já com critérios

de medida. Para ter qualidade, o produto precisa, no mínimo, atender esses

critérios que foram estabelecidos.

O RUP prevê duas atividades para assegurar a qualidade do produto.

Controle de Qualidade

Tem foco no produto e encontra defeitos específicos. Faz o teste no que foi

gerado, no final. Verifica se existe um defeito naquilo que foi produzido.

Garantia da Qualidade

O foco fica nos processos e na execução deles. Garante que você está

fazendo as coisas de maneira certa. Pode ser alcançado com utilização de

boas práticas de mercado e etc.

Qualidade é multidimensional e possui vários critérios ou dimensões.

Andamento: o progresso do projeto.

Variação: diferença entre planejado e executado.

Confiabilidade: o quanto seu produto é confiável?

Funcionalidade: os casos de uso foram implementados corretamente?

Desempenho: o desempenho está adequado às necessidades.

Muitos outros critérios podem ser utilizados para medir a qualidade, mas o

importante é que esses critérios sejam definidos antes da execução do projeto,

para que não sejam adaptados para dar uma falsa ideia de qualidade no final

de tudo.

A verificação da qualidade é importante porque o custo de uma correção sobe

exponencialmente com o passar do tempo. Os defeitos corrigidos após

implantação custam muito mais caro do que a correção durante o

desenvolvimento. A verificação da qualidade diminui os custos e os riscos.

Gerenciamento de Mudanças

Sempre que existe muito paralelismo no projeto, é preciso controlar o

ambiente. Quando existem vários desenvolvedores e equipes, diferentes locais

de desenvolvimento, muitas iterações, releases, produtos e plataformas

heterogêneas, se não existir um controle disciplindo do processo de

desenvolvimento, o projeto tende ao caos rapidamente.

Item de Configuração

Uma entidade que satisfaz algum propósito para o usuário final e que pode ser

unicamente identificado. Podem ser código-fonte, especificações, modelos,

artefatos e etc.

Primeiro é preciso identificar quais são esses itens que necessitam estar sob a

Gestão de Configuração.

Gerenciar Mudanças é utilizar uma abordagem sistemática para avaliar, decidir

sobre as mudanças e coordená-las. É o processo de coordenar, avaliar e

decidir sobre a realização de mudanças propostas naqueles itens que estão

sendo gerenciados.

Apenas as mudanças aprovadas são implementadas nos itens de

configuração, nos dados e documentos relacionados. É preciso avaliar o

impacto, pertinência e o custo-benefício antes de aprovar.

No RUP existem as atividades de :

Coordenação de atividades e artefatos: procedimento repetíveis para gerenciar

as mudanças nos artefatos.

Coordenação de iterações e releases: controle sobre os releases ao final das

iterações. (baseline)

Controle de mudanças no software: mantém uma estrutura bem definida para

grenciar mudanças no software.

RUP para Concursos Parte 4 - Fase de Iniciação e Disciplinas Modelagem de

Negócio e Requisitos

As disciplinas do RUP podem ser executadas em qualquer uma das fases. A

única exceção é a disciplina de implantação (deployment) que não é executada

na fase de iniciação (inception).

Fase de Iniciação ou Concepção

Na fase de iniciação, a ênfase é nas disciplinas de Modelagem de Negócios e

Requisitos que estão relalcionadas com definição de escopo, levantamento das

necessidades e entendimento dos processos de negócio da organização. Os

objetivos dessa fase e dessas disciplinas são semelhantes.

A maioria do esforço é feito na disciplina de Requisitos, mas na Iniciação você

já pensa na sua arquitetura candidata para fazer uma análise de viabilidade e

provas de conceito. Por isso, alguma coisa já será codificada e testada

também.

A meta principal é atingir o consenso sobre os objetivos do ciclo de vida do

projeto. Todos os interessados precisam chegar em um consenso. É uma fase

muito importante para projetos novos, onde os riscos são desconhecidos. É

preciso fazer análise de viabilidade, mapeamento de escopo e objetivos. Para

Ciclos de Evolução, pode ser uma fase mais rápida e até mesmo uma fase

opcional, caso a evolução seja simples.

Nessa fase você determina se continuar com o projeto compensa ou não. A

análise de viabilidade não trata apenas de código, mas é preciso verificar se o

projeto é financeiramente viável. Também é preciso fazer um estudo de

viabilidade técnica. Quais tecnologias e arquiteturas devem ser usadas? É

possível fazer o projeto nessas tecnologias?

Essas perguntas precisam ser respondidas para que a gerência possa

determinar se vale a pena ou não executar o projeto.

Objetivos da Fase de Iniciação

Estabelecer o escopo do software: qual é o escopo do meu produto? Que

requisitos considerar e quais deixar de fora? É determinado com o

levantamento dos casos de uso.

Estimar custos: quanto vai custar o software? Isso é uma estimativa inicial. A

cada iteração o custo é ajustado.

Estimar tempo : estimativa inicial de tempo. Também é ajustada a cada

iteração.

Estimar riscos: identificar os casos de uso arquiteturalmente significativos (os

mais críticos, complexos, arriscados e nebulosos) e principais cenários de

operação do sistema.

Propor pelo menos uma opção de arquitetura para alguns cenários básicos.

Principais Artefatos da Fase de Iniciação

Documento de Visão (disciplina de Requisitos): descreve as necessidades e

características mais importantes do sistema. Não é um artefato de engenharia

de software. É um documento de alto nível que dá uma visão geral do sistema

para o patrocinador do projeto, para servir como base para um contrato. Não

possui informações técnicas ou arquiteturais. Também pode conter uma

especificação de requisitos formal. Fornece informações para o processo de

aprovação do projeto e, portanto, está intrinsecamente relacionado ao Caso de

Negócio.

Caso de Negócio (disciplina de Gerenciamento de Projetos)

É um documento com informações do ponto de vista do negócio para

determinar se vale a pena investir no projeto sobre o ponto de vista do retorno

de investimento (ROI). Mostra a estimativa de custos. É este documento que

vai basear a decisão do patrocinador de continuar ou não com o projeto.

Plano de Desenvolvimento do Software (disciplina de Gerenciamento de

Projetos)

É como o Plano de Projeto do PMBOK e reúne as informações necessárias

para o gerenciamento do projeto durante todo o ciclo do desenvolvimento.

Modelo de Caso de Uso

Descreve os requisitos funcionais de um sistema em termos de Casos de Uso

e atores que interagem com os casos de uso. Determina o escopo do sistema.

Contém as funções pretendidas para o sistema e serve como um contrato

estabelecido entre os clientes e os desenvolvedores. O Modelo de Casos de

Uso mapeia os casos de uso que existem e determina o escopo, logo, o que

não está neste modelo, não deve ser feito.

O modelo de casos de uso é usado como fonte de informações essencial para

atividades de análise, design e teste.

Glossário

Conjunto consistente de definições para evitar mal entendidos. Define termos

importantes usados pelo projeto. Em muitos domínios, os termos não são

simples e é preciso garantir que toda a equipe tenha o mesmo entendimento

sobre os itens.

Disciplina Modelagem de Negócio

Entender a estrutura e a dinâmica da organização cliente ou organização-alvo,

identificando oportunidades de melhoria. Trata de aspectos anteriores ao

software. Antes de automatizar os processos da organização, é preciso

entender o problema da organização. Sem isso, corre-se o risco de

implementar um software que não resolve os problemas da empresa e não

agrega valor nenhum.

Assegurar que todos os interessados tenham um entendimento comum sobre a

organização.

Principais Papéis e Atividades:

Papel - Analista de Processo de Negócios

Identifica os processos na organização-alvo e descreve estes processos para

entender como a organização trabalha. Depois define o que pode e deve ser

melhorado. Em seguida propõe redesenho dos processos se for necessário.

Ele está entendendo os processos de Negócio, não existe nada de software

aqui.

Artefato Importante

Modelo de Domínio (modelo de objetos de negócio)

Lembrando que um modelo é um agrupamento de artefatos. Inclui diagramas,

especificações, entidades e etc.

É um modelo conceitual e mosta os tipos de objetos mais importantes para o

domínio. Como é um artefado da Modelagem de Negócio, que é anterior ao

software, não mostra entidades do software, apenas entidades do mundo real,

do negócio.

A figura acima mostra um diagrama de classes. Essas ainda são classes

conceituais de entidade e controle.

Relação com outras Disciplinas

Requisitos

Utiliza o Modelo de Negócio como informação fundamental para entender os

requisitos de sistema. Ou seja, os requisitos de sistema são derivados dos

requisitos de negócio.

Análise e Design

Utiliza as entidades de negócio para identificar classes de entidade no projeto,

que são as classes que representam a informação a ser armazenada.

Ambiente

Desenvolve e mantém artefatos de suporte como o Guia de Modelagem de

Negócios, que é um padrão que mostra como executar as atividades de

modelagem de negócio na organização.

Abmiente é uma disciplina que se relaciona com todas as disciplinas do RUP. É

ela quem configura o RUP, estabelece guias, padrões e seleciona as

ferramentas a serem utilizadas. Normalmente configura guias e padrões para

as outras disciplinas.

Disciplina Requisitos

É uma das disciplinas mais importantes porque estrutura os casos de uso e o

RUP é orientado a casos de uso. Estabelece o que o sistema deve fazer e

define as fronteiras (escopo) do sistema, que são as funcionalidades descritas

nos casos de uso.

Fornece uma base para planejar o conteúdo técnico das iteração e para

estimar o custo e o tempo do desenvolvimento do sistema. Tudo isso baseado

nos casos de uso.

Principais Papéis, Atividades e Artefatos:

Papel - Analista de Sistemas

É um dos papeis mais importante do RUP. Levanta os requisitos do sistema

(Atores e CDU´s). Estrutura o Modelo de Casos de Uso e diagramas de casos

de uso.

Papel - Especificador de Casos de Uso

O especificador é quem detalha a especificação dos casos de uso que foram

elvantados pelo analista. Faz o passo a passo, detalha os fluxos e etc.

Artefatos Importante para o Marco

Glossário - Explicado acima

Modelo de Casos de Uso

Modelo das funções que são pretendidas pelo sistema. Serve como contrato

entre o cliente e os desenvolvedores. Os requisitos funcionais do sistema são

dispostos aqui agrupados em diagramas de casos de uso. Além disso, contém

também as especificação dos casos de uso. Os requisitos não funcionais ficam

em um artefato chamado Especificações Suplementares, também da disciplina

de requisitos.

Documento de Visão - Explicado acima

Contém as necessidades e características mais importantes do sistema.

Fornece uma base de alto nível para que o leitor possa compreender o sistema

a ser desenvolvido. Não possui detalhes técnicos.

Relação com outras Disciplinas

Modelagem de Negócios

A Modelagem de Negócios fornece a entrada para a disciplina de Requisitos.

Fornece as regras de negócio e um contexto organizacional para que os casos

de uso sejam especificados.

Análise e Design

Usa a saída da disciplina de Requisitos como informações primárias dos

requisitos para realizar os Casos de Uso. Mostra como os casos de uso se

comunicam e se comportam. Pode encontrar falhas dos casos de uso.

Teste

Os Casos de Teste são gerados a partir dos casos de uso. Portanto, a saída

dos requisitos é usada como entrada para validação do sistema. O que gera os

objetivos do esforço de teste.

Gerenciamento de Configuração e Mudanças

Fornece o mecanismo de controle para as mudanças nos requisitos e isso se

repete nas outras disciplinas. É basicamente o controle de versão dos

artefatos.

Gerenciamento de Projeto

Usa o Modelo de Casos de Uso para planejar as iterações. É o Plano de

Iteração.

Ambiente

Desenvolve e mantém artefatos utilizados nessa disciplina. É a mesma coisa

para as outras disciplinas.

Marco da Fase de Iniciação: Objetivos do Ciclo de Vida

Marco é um resultado a ser alcançado. Um estado em que se encontra o

projeto e onde alguns critérios precisam ser satisfeitos. São os critérios de

avaliação da fase. É preciso responder sim a essas perguntas que

estabelecem os critérios de avaliação.

Os casos de uso definem claramente o escopo? Que é o grande objetivo da

fase de iniciação.

Caso necessário, foi possível fazer um protótipo da aquitetura? Se não foi

possível, seu sistema pode não ser viável.

Todos os riscos foram encontrados? Se sim, foram mitigados? Os riscos

precisam ser encontrados e deve existir um plano para tratar os casos de uso

mais complicados.

Existe condição de se fazer o projeto? Todos os interessados, os técnicos,

gerentes e usuários, precisam concluir que é possível fazer o projeto.

RUP para Concursos - Parte 5 - Fase de Elaboração e Discplina Análise e

Design

Fase de Elaboração

O que muda entre as fases é ênfase que se dá em cada disciplina e o marco

da fase. Na elaboração o foco é na disciplina de Análise e Design. Entretanto,

pode ser que todas as disciplinas sejam de fato executadas em uma fase,

dependendo do seu plano de iteração.

Na fase de Elaboração ainda existe muita atividade nas disciplinas Modelagem

de Negócios e Requisitos. O esforço maior dessa fase é na Análise e Design,

mas a Implementação já ocupa grande parte do esforço porque código

executável já é gerado para garantir a arquitetura estabilizada. Também

começam as atividades de Implantação.

A meta princpal da Elaboração é realizar os requisitos mais significativos do

sistema, com grande impacto na arquitetura e desenvolver uma arquitetura

exectuável (que funciona) e estabilizada, que garanta a continuidade do

projeto. Esses casos de uso são chamados de Arquiterualmente Significativos.

A estabilidade da arquitetura é avaliada através de protótipos arquiteturais.

Ao final da fase de Elaboração é gerado uma baseline arquitetural. Baseline é

uma versão revisada da arquitetura ou de algum artefato.

Objetivos da Elaboração

Garangtir que a arquitetua e os requisitos estejam estáveis para mitigar os

riscos.

"Ultrapassar esta marca (Elaboração) significa passar de uma operação de

baixo risco para uma operação de alto custo e alto risco". Nas duas primeiras

fases os custos são baixos, poucas pessoas estão envolvidas. Dessa fase em

diante a equipe aumenta. O custo e risco passam a ser significativos.

Tratar todos os riscos significativos do ponto de vista do projeto.

É aqui onde os riscos são de fato tratados. O RUP entende que estabilizar a

arquitetura é tratar riscos porque os piores casos de uso são implementados

neste momento.

Selecionar componentes e criar planos de iterações detalhados para a fase de

Construção

É preciso pensar quais componentes podem ser reutilizados no futuro.

Principais Artefatos

Protótipos

São usados de uma maneira direta para reduzir o risco e elicitar requistos

significativos. É a implementação de um conceito que precisa ser testado.

Documento de Arquitetura de Software

Fornece uma visão geral da arquitetura do sistema usando as 4+1 visões

(resumos anteriores) da arquitetura.

Modelo de Projeto

Modelo de objetos que descreve a realização dos casos de uso. Mostra como

implementar os casos de uso em termos de objetos com o passar do tempo.

Usa muito os diagramas comportamentais e de interação da UML, mostra

como acontece a comunicação entre os objetos do caso de uso. É uma

abstração do modelo de implementação e código-fonte.

Modelo de Dados

Modelo de implementação que descreve a representação conceitual, lógica ou

física dos dados persistentes no sistema.

Disciplina de Análise e Design (Projeto)

Objetivos

Transformar os requisitos em um projeto do sistema a ser criado. Os casos de

uso são realizados em um projeto. Os casos de uso nunca dizem como fazer,

mas apenas o que fazer. O projeto vai dizer como fazer, como realizar os casos

de uso.

Desenvolver uma arquitetura refinada para o sistema.

Adaptar o projeto para que corresponda ao ambiente de implementação

considerando restrições de técnologia.

O nome da disciplina é Análise e Design (projeto), mas as atividades são

distintas: análisar e projetar. Análise significa entender o problema,

normalmente sem considerar as tecnologias. São modelos conceituais, sem

restrições técnológicas.

No projeto você cuida da solução e de modelos concretos para o problema.

Leva em consideração as restrições técnológicas.

O RUP diz que as atividades de análise são opcionais e é possível ir

diretamente para o projeto. A análise está mais próxima do negócio e é

independente da tecnologia. O modelo de projeto é dependente da técnologia.

Então, o Modelo de Análise pode ser aproveitado para o projeto em qualquer

que seja a técnologia escolhida.

Principais Pepeis, Atividades e Artefatos

Arquiteto de Software

É o cara que projeta a arquitetura em cima dos casos de uso mais complexos.

Tem uma visão ampla do projeto.

Designer ou Projetista

É quem analisa e projeta os casos de uso em termos de classes. Esse é o

papel que entra nos detalhes de como os casos de uso serão feitos. Analisa os

casos de uso, projeta os casos de uso e projeta os subsistemas.

Projetista de Banco de Dados

Gera os modelos lógicos e físicos da sua base de dados para guardar as

entidades persistentes do sistema.

Protótipos

São feitos para provar ou esclarecer algum conceito. Podem ser categorizados

de algumas formas:

Quanto ao que eles exploram:

Comportamentos - enfatizam a exploração do comportamento do sistema.

Estruturas - trabalham questões arquiteturais ou técnológicas do sistema.

Quanto ao seu resultado:

Exploratório ou descartável - utilizado esclarecer algum requisito complicado ou

nebuloso e depois é descartado

Evolutivo - o protótipo é evoluído até se tornar o sistema de fato.

Documento de Arquitetrua de Software - Documento que descreve a

arquitetura e é feito pelo arquiteto de software. Já foi explicado antes.

Modelo de Design (ou de projeto) - descreve as realizações dos casos de uso e

serve como uma abstração do modelo de implementação. (modelos são

agrupamentos) Esse modelo diz como as coisas serão implementadas.

Relação com outras disciplinas

Modelagem de negócio - Fornece o contexo organizacional para o sistema.

Requisitos - Fornece as funcionalidades CRÍTICAS a serem implementadas.

Testes - Testa o sistema projetado durante a disciplina Análise e Design

Ambiente - Gera guias de análise e projeto, etc (a mesma coisa para as outras

disciplinas).

Gerenciamento de Projeto - Planeja as atividades da discplina (a mesma coisa

para as outras disciplinas).

Marco da Elaboração: Arquitetura do Ciclo de Vida

É o segundo marco mais importante do projeto. Considera a arquitetura

executável e a resolução dos riscos principais. Nessa fase os riscos são

resolvidos de fato e a arquitetura deve funcionar.

Critérios de Avaliação

A arquitetura está estável e robusta para comportar os requisitos atuais e

futuros?

Os riscos críticos foram resolvidos?

Os planejamentos de cronograma, orçamento e qualidade estão bem defindos?

Neste momento é mais fácil dar precisão aos planejamentos porque os riscos

já foram tratados.

Deve-se seguir com o sistema? (O RUP diz que esse é o momento de fechar o

contrato, porque é quando a arquitetura foi estabilizada, na vida real o contrato

é fechado antes.)

RUP para Concursos - Parte 6 - Fase de Construção e Disciplinas de

Implementação e Testes

Nesta fase os principais requisitos já foram identificados e elicitados. O modelo

de casos de uso está praticamente completo e a arquitetura já está definida.

Fase de Construção

Na fase de construção a ênfasa vai para as disciplinas de Implementação e

Testes.

Essa fase demanda várias iterações e alto paralelismo na equipe. Por isso, o

Gerenciamento de Configurações e Mudanças também possui muita ênfase

durante a fase de Construção.

O esforço principal é centrato na Implementação e nos Testes, mas ainda

podem existir casos de uso a serem especificados. E nessa fase é preciso

esclarecer os requisitos restantes. A arquitetura também pode passar por

evoluções e ajustes. Assim, as disciplinas de Requisitos e Análise e Design

também possuem boa atividade.

A disciplina de Implantação começa a crescer e ter mais atividades. Nela são

escritos os manuais de treinamento. As versões preeliminares dos manuais e

guias começam a ser feitas na elaboração, mas é na construção que isso

acontece com mais ênfase.

A conclusão do desenvolvimento acontece durante a construção com base na

arquitetura definida na elaboração.

Segundo o RUP, é um processo de manufatura. Pega-se o projeto e

implementa-se conforme projetado. (Na prática é BEM DIFERENTE)

Acontece também uma ênfase no gerenciamento de recursos e controle de

operações para alcançar maior produtividade e qualidade. Essas atividades

fazem parte do Gerenciamento de Configuração e Mudanças. O ambiente pode

ser caótico em projetos grandes e é preciso uma abordagem sistemática para

gerenciar esta fase.

Objetivos

Minimizar custos de desenvolvimento, otimizar recursos e evitar retrabalho. A

palavra chave é eficiência.

Disponibilizar as versões úteis (alfa, beta e etc) com rapidez. Os testes ALFA

são realizados durante a fase de Construção.

Concluir a análise, o projeto, o desenvolvimento e o teste de todas as

funcionalidades.

Verificar e decidir se o software está pronto para implantação.

Principais Artefatos

O Sistema (disciplina de implementação) - O próprio sistema executável, pronto

para iniciar os testes beta. Lembrando que os testes beta são executados na

Transição.

Plano de Implantação - guia a equipe de implantação e transição para eles

disponibilizarem o software. Essa é apenas uma versão inicial do plano, as

versões finais são feitas na Transição. Em projetos menores o Plano de

Implantação pode estar embutido no Plano de Desenvolvimento de Software.

Conjunto de Testes - Testes implementados e executados para validação e

estabilidade das versões (releases)

Disciplina de Implementação

Objetivos

Codificar! Implementar o sistema com qualidade. A qualidade desse código

depende da qualidade da Análise e do Projeto que foram feitos nas fases

anteriores.

Implementar o código em subsistemas e camadass. As classes devem ser

pensadas em termos de componentes para favorecer a reutilização do código.

Testar os componentes desenvolvidos como unidades (testes unitários). Testes

unitários são feitos pelos desenvolvedores e não por testadores.

Integrar os componentes gerados pelos implementadores individualmente em

um build único. O papel responsável pela integração é o Integrador.

Papeis, Atividades e Artefatos

Implementador - implementa os componentes e faz os testes unitários.

Integrador - integra os códigos e componentes do sistema em um build único.

Artefatos Importantes

O Sistema, Componentes, Builds

Relação Com Outras Disciplinas

Análise e Design fornece a principal entrada para a Implementação através do

Modelo de Design (projeto). A implementação do código é feita a partir dessa

entrada. Digramas de classes, sequência e etc.

Teste descreve como realizar o teste de integração de cada build. Os testes de

integração e os testes Alfa são descritos pela disciplina de testes.

Implantação descreve como utilizar o Modelo de Implementação para

empacotar e disponibilizar o sistema em um ambiente, além do preparo dos

materiais de treinamento.

Ambiente e Gerenciamento de Projeto funcionam como nos outros resumos.

Disciplina de Testes

Busca responder as seguintes perguntas: você conseguiu implementar a

solução que resolve o problema levantado anteriormente? Como você garante

que esse código realmente resolve o problema?

Objetivos

Localizar e documentar defeitos na qualidade do software. Testes são feitos

para encontrar defeitos e nunca garantem que o sistema está livre de defeitos.

Validar as suposições feitas nas especificações de design e requisito através

de uma demonstração de fato. Fala-se que são suposições porque a certeza só

aparece após os testes. No levantamento de requisitos os analistas estão

supondo que estão fazendo tudo correto.

Validar as funcionalidades dos software de acordo com o projeto e verificar se

os requisitos foram implementados de maneira correta.

Papéis, Atividades e Artefatos

Analista de Testes é quem elabora o Plano de Testes. É o plano que define os

objetivos dos testes para cada iteração. Se for o caso, pode ser feito um único

Plano de Testes Mestre, que serve para todas as iterações.

No Plano de Testes existem os objetivos, a abordagem dos testes (caixa

branca ou preta), os tipos de testes (desempenho, funcionais, segurança, etc).

O plano també informa quantas pessoas vão trabalhar com isso e quais serão

os documentos gerados pelos testes.

Projetista de Testes é quem gera os Casos de Teste, que são gerados a partir

dos cenários dos Casos de Uso. Os Casos de Teste são especificações de

entradas e saídas, mas os testes ainda precisam ser implementados depois

disso.

Testador é quem vai implementar e executar os testes.

Artefato Importante para o Marco - Conjunto de Testes - execução, geração de

relatórios e logs de execução dos testes.

Relacionamento Com Outras Disciplinas

Requisitos - fornece os casos de uso para a geração dos casos de teste.

Fornece a base para geração dos testes.

Análise e Design: fornece o projeto e a arquitetura que devem ser testados.

Implementação: produz os componentes e builds que serão testados.

As disicplinas de Suporte funcionam como nos outros resumos.

Ambiente: prepara os guias, padrões e ferramentas.

Gerenciamento de Projetos: planeja as atvividades de testes para a iteração.

Gerenciamento de Controle e Mudanças: controlar, gerencia e versiona os

artefatos de testes.

Marco da Construção: Capacidade Operacional Inicial

O produto está pronto para ser passado para a equipe de Transição. Todas as

funcionalidades foram desenvolvidas e os testes ALFA foram concluídos.

Testes ALFA e BETA são testes de aceitação do sistema. O usuário testa o

sistema para aceitá-lo.

Os testes ALFA são realizados no final da fase de Construção e conduzidos

por um conjunto restrito dos usuários finais, os mais importantes e experiêntes.

O teste acontece NO AMBIENTE DE DESENVOLVIMENTO. É um teste

controlado.

O manual do usuário é produzido e existe uma descrição do release atual.

Critérios de Avaliação

O produto está estável para ser implantado? Os problemas mais graves foram

identificados e resolvidos? O resultado está coerente com o planejado? Os

envolvidos estão prontos para a Transição?

RUP para Concursos - Parte 7 - Fase de Transição e Discipina de Implantação

Fase de Transição

Durante essa fase a ênfase é na disciplina de Implantação. Que é a disciplina

que cuidaa da disponibilização do software para o usuário final. As outras

disciplinas de engenharia possuem muito pouca ou nenhuma atividade.

Outra disciplina importante é a Gestão de Configuração e Mudança. Ela dá o

suporte para se estabelecer as versões que são implantadas para os usuários

finais e os itens de configuração de cada realease.

Mais de 70% do esforço é direcionado para a disciplina de Implantação. Quase

tudo já deve ter sido feito nas disciplinas anteriores. O que sobra para a

Transição deve ser apenas ajustes finos em função dos testes Beta (no

ambiente do usuário).

O foco dessa fase é disponibilizar o software ao usuário final. Podem acontecer

várias iterações e em cada uma delas o release é testado e os ajustes são

feitos de acordo com o feedback dos testes.

O feedback do usuário deve ser em relação a ajustes finos, normalmente com

relação a usabilidade e visual. Os problemas mais graves devem ter sido

tratados nas fases anteriores. Não faz sentido mexer na arquitetura ou tratar

questões de segurança neste momento.

Essa fase pode ser muito rápida, ou muito demorada e complexa, dependendo

do tipo de produto e ajustes que devem ser feitos.

Teste Beta para validar o novo sistema. Os testes Beta são realizados para

obter a aceitação do usuário, no ambiente real de produção e sem

acompanhamento direto do desenvolvedor.

Treinamento de usuários e equipe de manutenção. Os usuários devem

aprender a utilizar o sistema.

Atividades de ajuste: correção de erros, melhorias de desempenho e

usabilidades.

Consentimento dos envolvidos dizendo que o software atende ao que se

necessitava no início.

Principais Artefatos

Notas de Release (release notes) - textos informando o que mudou de uma

versão para a outra, quais erros foram corrigidos e quais são as novas

funcionalidades.

Artefatos de Instalação - tudo o que é necessário para instalação do softwares:

scripts, arquivos de configuração e etc.

Material de Treinamento - Guias do usuário, manuais do sistema e etc.

Disciplina de Implantação

Objetivos

Coordenar e gerenciar os testes beta, que são testes de aceitação. A

abordagem dos testes foi definida pela disciplina de Teste durante a

construção, mas o gerenciamento dos testes é feito na Implantação.

Desenvolver os artefatos de instalação e materiais de treinamento.

Liberar para fabricação (liberação e instalação no ambiente alvo)

O RUP define 3 tipos de instalação do produto

- Instalação personalizada - necessita de configuração do ambiente para o

usuário. É a mais complexa.

- Produto em uma forma compacta - disponibilizado em uma mídia para o

usuário instalar

- Acesso ao software por meio da Internet - link para download do produto

Papéis, Atividades e Artefatos

Gerente de Implantação - é quem desenvolve o plano de implantação, tudo que

precisa ser feito para a implantação, inclusive as notas de release.

Desenvolvedor do Curso - é quem prepara os materiais e guias de treinamento.

Implementador - é quem implementa os artefatos de instalação: instalador,

arquivos de configuração, scripts de instalação e etc.

Artefatos: Builds do produto, notas de release, aretafos de instaslação e

material de treinamento.

Relação com Outras Disciplinas

Requisitos - é a fonte principaal para elaboração de material de suporte e

treinamento.

Teste - testes são fundamenteias para a implantação do sistema e aceite do

usuário.

Ambiente, Gerenciamento de Projeto e Gerenciamento de Configuração e

Mudanças funcionam da mesma forma que nas outras disciplinas.

Marco da Implantação: Release do Produto

Implantação da versão 1.0 e depois decide-se se os objetivos foram todos

alcançados e se deve existir outro ciclo de desenvolvimento para geração de

uma nova versão, uma versão 2.0 por exemplo.

Critérios de Avaliacão

As despesas reais com recursos são aceitáveis quando se compara com o que

foi planejado?

O usuário está satisfeito? O sistema atende às necessidades do usuário?

RUP Para Concursos - Parte 8 - Disciplinas de Surpote

Disciplinas de Suporte - Gestão de Configuração e Mudanças

Controla as mudanças feitas nos artefatos de um projeto e mantém a

integridade entre eles.

Na atividade de Gerenciamento de Solicitações de Mudança (CRM) você

recebe as solicitações de mudança. Analisa em termos de impacto e risco, vê o

custo benefício e aprova ou recusa a solicitação.

No Gerenciamento de Configuração você identifica os itens de configuração,

que são todas aquelas coisas que possuem valor no ambito do seu projeto e

que percisam ter a configuração controlda. Esses itens são armazenados em

um respositório. É preciso manter esses itens de configuração armazenados,

controlados e versionados.

Na Medição você gera relatórios a respeito das mudanças nos itens de

configuração e com isso pode responder algumas questões gerenciais a

respeito do processo de mudança e configuração. Quantas mudanças estão

pendentes? Quanto tempo leva para uma mudança ser implementada?

Objetivos

Identificar e controlar itens de configuração

Restringir as mudanças nesses itens

Auditar as mudanças nos itens - checar se a baseline do projeto contém todos

os itens de configuração necessários.

Evitar confusões de atualização simultânea - na fase de construção existem

muitas equipes trabalhando em paralelo e isso evita que muitas pessoas

atualizem o mesmo aretefato ao mesmo tempo.

Evitar Notificicação Limitada - uma pessoa atualiza um artefato que é de

interesse de outras pessoas, mas elas não ficam sabendo dessa atualização.

Controle de Versão - controla as versões dos artefatos.

Benefícios

Estabilidade maior do produto, já que só as mudanças aprovadas são

implementadas. Suporte a métodos de desenvolvimento porque várias equipes

podem trabalhar ao mesmo tempo em um ambiente controlado. (isso precisa

ser aprofundado)

Restrição de mudanças feitas nos artefatos, que seguem as políticas do projeto

e uma trilha de auditoria que diz quando e por quem um artefato foi alterado. A

gerência tem o controle dos artefatos do projeto.

Principais Papéis, Atividades e Artefatos.

Gerente de Configuração - Configura o ambiente de gerencia de configuração e

estabelece as políticas dessa gerência.

Gerente de Mudanças - estabelece o processo de controle de mudanças e

aprova ou não as solicitações de mudança.

Repositório do Projeto e As Solicitações de Mundança são os artefatos

importantes.

Disciplina Gerenciamento de Projeto

Gerenciar pessoas, equipes, fases e iterações para executar e monitorar o

projeto. Planejar o cronograma, gerenciar a qualidade e gerenciar os riscos do

projeto.

Gerencia o tempo através do cronograma, os critérios de qualidade através do

plano de gerenciamento de qualidade. Gerencia os riscos, que são mapeados

na fase de iniciação, com a matriz de riscos e é criada a estratégia de

mitigação dos riscos.

Gerenciamento de pessoal, contrato com fornecedores e gestão de orçamento

não estão incluídos no RUP. Que recomenda o PMBOK para essas coisas. A

visão do gerenciamento de projetos do RUP é limitada.

O planejamento de projeto no RUP ocorre em dois níveis. Há uma baixa

granularidade ou Planos de Fase que descrevem todo o projeto e uma série de

alta granularidade ou Planos de Iteração que descrevem os passos iterativos.

Esta disciplina concentra-se principalmente em 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,

processo de acompanhamento de um projeto iterativo e métricas. No entanto,

esta disciplina do RUP não tenta cobrir todos os aspectos do gerenciamento de

projetos.

Principais Papéis, Atividades e Artefatos

Gerente de Projetos - Um papel atuante em todas as fases do RUP e com

atuações diversas. Possiu várias atividades, dentre elas: planejar fases e

iterações, identificar e avaliar os riscos, monitorar o andamento do projeto e

etc. É o cara que resolve os problemas.

Plano de Desenvolvimento de Software, que é um planejamento macro do

projeto.

Planos de Iteração - os planos para cada iteração

Lista de Riscos

Disciplina Ambiente

Configura o processo para o projeto de forma adequada a realidade da

organização. Customiza o RUP. O que não é útil para a sua organização deve

ser removido.

No Ambiente você seleciona e adquire as ferramentas que são úteis.

Desenvolve ou adapta os templates para as outra disciplinas do projeto,

também desenvolve e adapta os guias das atividades.

Oferece a organização para o AMBIENTE de desenvolvimento de software que

dará suporte à equipe de desenvolvimento.

Principais Papéis, Atividades e Artefatos

Engenheiro de Processo - é quem vai configurar o RUP para a organização.

Uma pessoa especialista no framework. É quem inicia o Caso de

Desenvolvimento.

Especialista em Ferramentas - é quem seleciona, adquire e configura as

ferramentas.

O Caso de Desenvolvimento é o principal artefato e é o que configura o RUP

para o seu contexto.

Descreve o processo de desenvolvimento que será usado pela organização. É

a personalização do RUP adaptada ao projeto. É um documento dinâmico. É

criado no início da fase de iniciação, mas é alterado durante todo o projeto. A

cada iteração e fase, novas disciplinas são adicionadas a este documento.

Esta disciplina é uma das mais importantes e a ausência dela é uma das

maiores falhas em projetos. Já que o RUP é grande demais.