Download - RUP para Concursos
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.