RUP para Concursos

O RUP um produto da IBM em formato de um framework de processos adaptvel. No devemos pegar este framework e aplicar tudo o que est escrito. necessrio entend-lo e configurar a estrutura do RUP para adapt-lo realidade da sua organizao. RUP um modelo prescritivo (diz como as coisas devem ser feitas) que fornece atividades, artefatos e guias que geralmente recomendam a utilizao de outros produtos da IBM e da linguagem de modelagem UML. Em provas o RUP tratado como processo de desenvolvimento ou metodologia.

Caractersticas do RUP Iterativo e Incremenntal O ciclo de vida do produto divido em iteraes, que so 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 so 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 esto maepadas nos casos de uso.

Orientado a Objetos Os componentes so baseados em objetos e colaboram entre si para implementar (realizar) os casos de uso.

Planejado por Riscos Os riscos so analisados a todo tempo e aqueles que MAIS CRTICOS so tratados prioritariamente. Os casos de uso arquiteturalmente significativos (os mais difceis, nebulsos, crticos, arriscados, etc) so os primeiros a serem implementados.

Grfico das Baleias O RUP compostos por 4 fases e 9 disciplinas.

No grfico voc percebe dois eixos. O eixo horizontal, a primeira dimenso ou a dimenso dinmica 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 (Iniciao, Elaborao, Construo e Transio). Cada fase possui vrias iteraes e d nfase em determinadas disciplinas, cada disciplina possui mais importncia em determinada fase e menor importncia em outra fase. A iterao 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 alcanado e estabilizado. Cada fase possui o seu marco. Determina o fim da fase.

O eixo vertical, segunda dimenso ou eixo esttico, onde so representadas as disciplinas (agrupamento das atividades de engenharia de software, por rea de interesse ou natureza das atividades). esttico porque as atividades a serem executadas so sempre as mesmas, no variam de acordo com o tempo. Um determinada disciplina possui as mesmas atividades em todas as fases. Assim, o eixo esttico no 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, papis, artefatos e produtos de trabalho. So 9 disciplinas no total. 6 de engenharia (Modelagem de Negcios, Requisitos, Anlise e Design, Implementao, Teste e Implantao) e 3 de suporte (Gerenciamento de Configurao e Mudana, Gerenciamento de Projeto e Ambiente)

No grfico, quanto maior a rea que uma disciplina ocupa em determinada fase, maior a nfase naquela disciplina durante a fase. Todas as disciplinas so consideradas em todas as fases, mas algumas possuem maior atividade e outras possuem menor ou nenhuma atividade em determinado momento.

O RUP tem duas dimenses.

A primeira dimenso, eixo horizontal, representa o aspecto dinmico do processo. Expresso em fases, marcos e iteraes.

A segunda dimenso, eixo vertical, representa o aspecto esttico do processo.

Expresso em componentes, disciplinas, atividades, artefatos, papis e etc.

RUP para Concursos - Parte 2 - Metodologia e Conceitos Chave

Metodologia composta por um Processo de Desenvolvimento que configurado especificamente para a sua organizao. composta por um conjunto de mtodos e prticas bem definidos e que possuem responsveis (papis), entradas, sadas e ordem de precedncia. Inclui ferramentas, tecnologias, pessoas, padres e guias.

Ao instnciar um processo de desenvolvimento baseado no RUP, o que se est procurando definir quem faz (papis), o que feito (produtos de trabalho) , como feito (descries das tarefas) e quando feito (fluxos de trabalho). Nas disciplinas existem papis 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 no a metodologia RUP em s. A organizao deve pegar o RUP e adapt-lo de acordo com as necessidades e assim, criar o seu prprio processo de desenvolvimento de software.

A metodologia conta com alguns componentes: Modelos, padres, guias, equipes treinadas, linguagem padro (UML) e ferramentas de automao.

Benefcios da Metodologia embasada no RUP:

Qualidade de Software atravs da utilizao das melhores prticas 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 caractersticas acima, o controle de riscos e a disciplina de gerncia de projetos do RUP levam a um Maior controle sobre custos e prazos.

Conceitos Chave do RUP

As 4 Fases do RUP So as etapas dos projeto de desenvolvimento com base no RUP. (1 eixo, Eixo Dinmico do Grfico das Baleias). Cada fase termina com um marco.

Concepo / Iniciao Determinar o escopo do projeto para que seja possvel estimar custos e riscos do projeto. gerado um macro-planejamento. Estima-se o tamanho do projeto, os custos e os riscos. So definidos os objetivos que a organizao pretende alcanar com o projeto. Todas as partes interessadas devem entender os objetivos a serem alcanados.

Elaborao Assegura que os principais riscos foram diminudos e uma arquitetura estvel foi definida. Dentre os casos de uso, que foram definidos na fase anteior, aqueles mais arriscados, importantes e complexos so identificados e implementados para garantir que a arquitetura est adequada. Isso j reduz o risco do projeto. O marco a aquitetura do projeto estabilizada.

Construo Desenvolver o produto de forma iterativa e incremental para a Transio. 20% dos casos de uso foram detalhados e implementados at a fase de Elaborao. Aqui os outros casos de uso so 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.

Transio Disponibilizar o software para o usurio final. Assegurar que o sistema esteja disponvel e funcionando corretamente. Inclui documentao do sistema, guias do usurio e etc. O marco o lanamento do produto.

As fases no so idnticas em termos de esforo e tempo gasto. Abaixo esto alguns nmeros mgicos da metodologia.

Iniciao Esforo

Elaborao Construo Transio

~5 % 20 % 65 % 10% 10 % 30 % 50 % 10%

Programao (Cronograma)

possvel ver que a fase Construo a que consome maior tempo (50%) e maior esforo (65%).

Uma passada pelas quatro fases chamada de Ciclo de Desenvolvimento e gera uma primeira verso do seu software, o que seria a verso 1.0. Uma prxima verso, de evoluo do software, seria a verso 2.0. Essa segunda parte considerada um novo ciclo e conhecida como Ciclo de Evoluo.

Durante o Ciclo de Evoluo a nfase nas fases no a mesma do Ciclo de Desenvolvimento. Na maioria dos casos, os riscos j so conhecidos e arquitetura j est estabilizada, ento, a fase de elaborao, por exemplo, ser menor.

Iteraes "Uma sequncia distinta de atividades que resulta em um release do seu produto". Uma iterao uma passada pelas 6 disciplinas de ENGENHARIA do seu projeto. As iteraes podem ser consideradas como mini-projetos em cascata.

As 6 disciplinas de engenharia so: Modelagem de Negcios, Requisitos, Anlise e Design, Implementao, Teste e Implantao.

A cada iterao as atividades de cada disciplina so executadas e no final gerado um produto de trabalho (release), que um incremento no sistema. Pode ser um release interno (para a equipe ou usurios especficos) 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 estvel e aprovado que libera o release.

Cada fase possui vrias iteraes. O que muda de uma fase/iterao para outra a enfase que dada nas disciplinas. Durante a passagem por uma disciplina pode no haver necessidade de executar nenhuma atividade de uma disciplina especfica. Isso acontence principalmente no incio e no fim do projeto.

Disciplinas Conjunto de atividades (fluxo de trabalho) relacionadas a uma rea de interesse do projeto para gerao de resultados. As disciplinas do RUP lembram as fases do modelo em cascata, porque so as atividades tcnicas que so executadas durante o projeto. Detalham como executar as atividades, quem executa e quais produtos de trabalho so gerados aps a execuo das atividades.

Algumas disciplinas esto associadas a conjuntos especficos de modelos e os modelos so conjuntos de artefados. Cada disciplina possui seu prprio fluxo de trabalho, que um diagrama de atividades da linguagem UML.

Disciplinas de Engenharia Modelagem de Negcios Requisitos Anlise e Projeto Implementao Testes Implantao

Disciplinas de Suporte Gerenciamento de Projetos Gerenciamento de Configurao e Mudanas Ambiente

M-RAITIGGA

Papis Definem o comportamento e as responsabilidades em um processo. Dentro de uma disciplina, os responsveis por executar as atividades so os papis. Exemplos de papis so: programador, testador, gerente de projeto, arquiteto e etc.

No final das contas, os papis acabam associados a um ser humano, mas a definio de um papel trata de um comportamento e de um conjunto de responsabilidades. Uma pessoa pode executar um, nenhum ou vrios papis.

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. So compostas por: finalidade, passos, entradas e sadas, papel responsvel, alm de guias e padres para auxiliar a execuo.

Produtos de Trabalho So o resultado de um processo de trabalho utilizados como entradas e/ou sadas na execuo das atividades. So divididos em artefatos (termo genrico), entregveis (os que so entregados aos clientes) e os resultados (outcomes), que so produtos intangveis, representam o alcance de algum objetivo. No geral, produtos de trabalho so chamados de artefatos.

Podem ser: modelos, documentos, cdigo fonte, executveis, etc

Resumindo: Papis executam Tarefas que geram Artefatos. Exemplo: O Especificados de Requisitos (papel) executa Atividade chamada Detalhar Caso de Uso e gera um artefato, que o prprio Caso de Uso.

Um ciclo de vida de desenvolvimento no RUP a passagem pelas quatros fases: Iniciao, Elaborao, Construo e Transio. Cada fase possui seus objetivos prprios e so delimitadas por marcos. Quando uma fase executada e seus objetivos so alcanados, o marco alcanado. Cada fase pode ter N iteraes, que so as passadas sequenciais pelas 6 disciplinas de engenharia do projeto. Dentro das disciplinas existem os papis que executam as atividades e geram artefatos.

RUP para Concursos - Parte 3 - As 6 Melhores Prticas do RUP

Desenvolvimento Iterativo uma estratgia de resoluo de problemas. Percorre-se vrias vezes as disciplinas de engenharia durante o ciclo de vida do projeto. Cada iterao uma passada pelas disciplinas e a cada uma delas a equipe aprende e ganha compreenso a respeito do projeto, dos requisitos e dos componentes. A arquitetura se torna mais robusta a cada incremento. uma maneira mais flexvel 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 iterao.

Lida com mudanas com mais facilidade. A cada incremento existe a chance de se verificar as mudanas nos requisitos e possvel se adaptar e replanejar o projeto. O replanejamento acontece a cada iterao.

Diminui os riscos porque so avaliados mais cedo. A cada iterao possvel integrar o cdigo, verificar as interfaces e os usurio tambm podero 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 iterao os usurios avaliam o que foi feito, passam o feedback e possvel corrigir os rumos do projeto. O conhecimento do negcio aumenta de forma mais precisa a cada interao com os usurios.

Aumenta o reuso porque mais fcil pensar em reutilizar um componente que j est parcialmente ou totalmente implementado do que pensar em todos os componentes de forma antecipada. quase impossvel prever estes componentes apenas com os casos de uso especificados.

As iteraes incorporam um conjunto quase sequencial das atividades. S no sequencial de fato porque algumas disciplinas podem no 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 propsito do seu cliente. uma condio ou restrio com a qual o sistema dever estar em conformidade. No adianta implementar um requisito errado da melhor forma do mundo, porque isso no 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 no funcionais.

O RUP diz que o documento de requisitos deve ser feito de maneira clara. E o Gerenciamento de requisitos uma abordagem sistemtica para localizar,

documentar, organizar e controlar os requisitos variveis em um sistema. Alm disso preciso manter a integridade dos requisitos atravs da rastreabilidade.

Os requisitos possuem vrios problemas: nem sempre so claros e podem vir de vrias fontes diferentes. Cada fonte tem a sua viso e a sua prioridade. Duas fontes diferentes podem ter vises conflitantes. Alm disso, existe uma interdependncia entre requisitos diversos e os documentos devem tratar isso de forma consistente.

Cada requisito diferente. A complexidade muda e a importncia tambm. Alguns so 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 vrias partes interessadas e pode haver conflito de interesses entre as essas partes. Alm disso, o nmero de requisitos pode se tornar to grande que fica impossvel gerenci-los.

Os requisitos so alterados a todo tempo. Mudanas de requisitos identificadas tardiamente so as principais causas de insucesso nos projetos de desenvolvimento de software.

Como gerenciar essas dificuldades? Analisando o problema. Entenda o "problema por trs do problema". Estabelea um vocabulrio comum (UML e Glossrio). Proponha solues em alto nvel: nvel de anlise e no em nvel 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 tcnicas de elicitao de requisitos. Faa acordos, balancie prioridades, ou seja, negocie com as partes interessadas para saber o que crtico, o que importante, o que desejvel e dispensvel. Alguns requisitos so fundamentais para entrada em produo. Outros no.

Defina o sistema. Defina o que o sistema deve fazer, em termos gerais, utilizando linguagem natural e linguagem grfica (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? Estabelea as prioridades para selecionar o que entra e o que sai.

Gerencie os requisitos variveis Garanta que os requisitos tenham uma estrutura que os tornem facilmente atualizveis (utilize referncias em seus documentos de casos de uso). Rastreie as mudanas em seus requisitos. Toda vez que uma mudana afetar um requisito ela deve ser analisada, o impacto e os riscos devem ser considerados e s poder ser executada se aprovada aps a anlise. Mudanas sem anlise no devem ser implementadas.

Os Casos de Uso guiam o desenvolvimento O RUP recomenda a utilizao de Casos de Uso como mtodo para a organizao dos requisitos funcionais. Assim voc consegue organizar uma viso de como o usurio enxerga o sistema.

Os casos de uso definem um conjunto de cenrios e cada cenrio descreve o comportamento do sistema em uma sequncia de aes. Esses cenrios devem produzir um resultado de sucesso ou de erro de valor observvel para um ator.

Atores so 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 compreeno do comportamente do sistema e para aprovao do funcionamento antes da implementao. Os arquitetos analisam os casos de uso para definir a

arquitetura do sistema logo na fase de elaborao. Os analistas, projetistas e programadores para entender o comportamento do sistema, refinar e implementar. Os casos de testes tambm so 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 organizao ou estrutura de componentes significativos que interagem atravs de interfaces". A arquitetura de um sistema reflete as grandes decises a respeito da implementao. Diz em quantas camadas o sistema feito, quais frameworks so utilizados, quais padres de projeto foram implementados e coisas do tipo. E o RUP d grande nfase arquitetura.

Segundo o RUP a arquitetura do software inclui: As decises significativas sobre a organizao de um sistema. A seleo dos elementos estruturadores e suas intefaces, a especificao dos elementos do sistema e como eles colaboram entre si.

A arquitetura no se preocupa apenas com estrutura e comportamento, mas tambm com funcionlidades, desempenho, segurana, reuso,

manutenibilidade, decises tcnolgicas e econmicas. Por isso os requisitos no funcionais, podem influenciar fortemente na deciso da arquitetura.

O que um Componente? uma parte independente do seu sistema. Grupos de cdigo coesos com interfaces e comportamentos bem definidos. Possui forte encapsulamento de contedo. Pode ser substitudo por outro. Os componentes se comunicam atravs de suas interfaces visveis 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

clssico: 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 mantm a integridade do sistema. A separao em componentes permite que os problemas sejam tratados de forma separada, j que eles so isolados. Isso identifica, isola, projeta, desenvolve e testa as partes bem formadas do sistema em separado.

possvel utilizar componentes de prateleiras disponveis no mercado.

Vises Arquiteturais No RUP a arquitetura representada por uma srie de vises de arquitetura diferentes. So perpectivas diferentes da arquitetura. Conhecido como modelo de viso 4 + 1 porque so 5 vises disponveis. Seria como a construo de uma casa, ondem existem vrios projetos diferentes. Um arquitetnico, um de instalaes eltricas, um de hirulica e etc.

Viso Lgica ou Viso de Projeto descreve as principais classes no projeto do sistema. Define as classes de projeto mais importantes, a organizao em

pacotes e subsistemas, e a organizao destes pacotes em camadas. uma das principais vises e obrigatria. Os diagramas de classes, sequencia e pacotes aparecem muito nesta viso.

Viso de Implementao contm a organizao em termos de mdulos, pacotes e camadas. uma viso opcional que entra nos detalhes da Viso Lgica. Descreve o cdigo da sua aplicao. Tudo o que foi gerado a partir do projeto. Viso mais detalhada do projeto do sistema.

Viso de Processos descreve o ascpecto simultneo do sistema. As tarefas (processos e threads) que so concorrentes devem ser definidas nessa viso. S deve ser usado caso o sistema possua alto grau de paralelismo. Por isso opcional.

Viso de Implantao descreve como sero as configuraes das instalaes fsicas do sistema. Contm a descrio dos vrios ns fsicos do sistema e a aloo de tarfas atribudas a eles. uma viso opcional, que pode ser usada quando o sistema for distriudo.

Viso de Caso de Uso uma viso externa, o ponto de vista do cliente a respeito da perspectiva funcional. Contm os casos de uso e cenrios que abrangem comportamentos significativos em termos de arquitetura, classes, ou riscos. uma viso obrigatria do documento de arquitetura.

Modelagem Visual (UML) Fazer uso de notao grfica para exibir o projeto do software. A linguagem grfica permite que o nvel de abstrao seja aumentando, escondendo detalhes e faciliando a comunicao com os clientes. Um usurio no consegue entender o cdigo e a linguagem escrita muito ambgua para isso. Essa notao visual tambm adiciona preciso captura dos requisitos. Como a ambiguidade reduzida, acontece uma melhora na comunicao da equipe.

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

UML uma notao padro para modelagem de software. Oferece diferentes perspectivas de um problema: esttica, dinnima, colaborativa e etc. Ajuda a manter o projeto (os diagramas) e o cdigo consistentes.

Os

artefatos

UML

possuem

suporte

das

ferramentas

automatizadas

recomendadas pelo RUP para ajuda na produtividade da equipe.

Verificao da Qualidade Qualidade no algo pontual, no deve ser verificada apenas no fim ou em pontos especficos, mas em todo o seu projeto de forma contnua. "A caracterstica de ter demonstrado a realizao de um produto que atende ou excede os requisitos acordados, conforme avaliado por medidas e critrios acordados".

Voc deve estabelecer os critrios de qualidade anteriormente, j com critrios de medida. Para ter qualidade, o produto precisa, no mnimo, atender esses critrios que foram estabelecidos.

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

Controle de Qualidade Tem foco no produto e encontra defeitos especficos. 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 execuo deles. Garante que voc est fazendo as coisas de maneira certa. Pode ser alcanado com utilizao de boas prticas de mercado e etc.

Qualidade multidimensional e possui vrios critrios ou dimenses. Andamento: o progresso do projeto. Variao: diferena entre planejado e executado. Confiabilidade: o quanto seu produto confivel? Funcionalidade: os casos de uso foram implementados corretamente?

Desempenho: o desempenho est adequado s necessidades.

Muitos outros critrios podem ser utilizados para medir a qualidade, mas o importante que esses critrios sejam definidos antes da execuo do projeto, para que no sejam adaptados para dar uma falsa ideia de qualidade no final de tudo.

A verificao da qualidade importante porque o custo de uma correo sobe exponencialmente com o passar do tempo. Os defeitos corrigidos aps implantao custam muito mais caro do que a correo durante o desenvolvimento. A verificao da qualidade diminui os custos e os riscos.

Gerenciamento de Mudanas Sempre que existe muito paralelismo no projeto, preciso controlar o ambiente. Quando existem vrios desenvolvedores e equipes, diferentes locais de desenvolvimento, muitas iteraes, releases, produtos e plataformas heterogneas, se no existir um controle disciplindo do processo de desenvolvimento, o projeto tende ao caos rapidamente.

Item de Configurao Uma entidade que satisfaz algum propsito para o usurio final e que pode ser unicamente identificado. Podem ser cdigo-fonte, especificaes, modelos, artefatos e etc.

Primeiro preciso identificar quais so esses itens que necessitam estar sob a Gesto de Configurao.

Gerenciar Mudanas utilizar uma abordagem sistemtica para avaliar, decidir sobre as mudanas e coorden-las. o processo de coordenar, avaliar e decidir sobre a realizao de mudanas propostas naqueles itens que esto sendo gerenciados.

Apenas

as

mudanas

aprovadas

so

implementadas

nos

itens

de

configurao, nos dados e documentos relacionados. preciso avaliar o impacto, pertinncia e o custo-benefcio antes de aprovar.

No RUP existem as atividades de : Coordenao de atividades e artefatos: procedimento repetveis para gerenciar as mudanas nos artefatos.

Coordenao de iteraes e releases: controle sobre os releases ao final das iteraes. (baseline)

Controle de mudanas no software: mantm uma estrutura bem definida para grenciar mudanas no software.

RUP para Concursos Parte 4 - Fase de Iniciao e Disciplinas Modelagem de Negcio e Requisitos As disciplinas do RUP podem ser executadas em qualquer uma das fases. A nica exceo a disciplina de implantao (deployment) que no executada na fase de iniciao (inception).

Fase de Iniciao ou Concepo Na fase de iniciao, a nfase nas disciplinas de Modelagem de Negcios e Requisitos que esto relalcionadas com definio de escopo, levantamento das necessidades e entendimento dos processos de negcio da organizao. Os objetivos dessa fase e dessas disciplinas so semelhantes.

A maioria do esforo feito na disciplina de Requisitos, mas na Iniciao voc j pensa na sua arquitetura candidata para fazer uma anlise de viabilidade e provas de conceito. Por isso, alguma coisa j ser codificada e testada tambm.

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 so desconhecidos. preciso fazer anlise de viabilidade, mapeamento de escopo e objetivos. Para Ciclos de Evoluo, pode ser uma fase mais rpida e at mesmo uma fase opcional, caso a evoluo seja simples.

Nessa fase voc determina se continuar com o projeto compensa ou no. A anlise de viabilidade no trata apenas de cdigo, mas preciso verificar se o projeto financeiramente vivel. Tambm preciso fazer um estudo de viabilidade tcnica. Quais tecnologias e arquiteturas devem ser usadas? possvel fazer o projeto nessas tecnologias?

Essas perguntas precisam ser respondidas para que a gerncia possa determinar se vale a pena ou no executar o projeto.

Objetivos da Fase de Iniciao

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 iterao o custo ajustado.

Estimar tempo : estimativa inicial de tempo. Tambm ajustada a cada iterao.

Estimar riscos: identificar os casos de uso arquiteturalmente significativos (os mais crticos, complexos, arriscados e nebulosos) e principais cenrios de operao do sistema.

Propor pelo menos uma opo de arquitetura para alguns cenrios bsicos.

Principais Artefatos da Fase de Iniciao

Documento de Viso (disciplina de Requisitos): descreve as necessidades e caractersticas mais importantes do sistema. No um artefato de engenharia de software. um documento de alto nvel que d uma viso geral do sistema para o patrocinador do projeto, para servir como base para um contrato. No possui informaes tcnicas ou arquiteturais. Tambm pode conter uma especificao de requisitos formal. Fornece informaes para o processo de aprovao do projeto e, portanto, est intrinsecamente relacionado ao Caso de Negcio.

Caso de Negcio (disciplina de Gerenciamento de Projetos) um documento com informaes do ponto de vista do negcio 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 deciso do patrocinador de continuar ou no com o projeto.

Plano de Desenvolvimento do Software (disciplina de Gerenciamento de Projetos) como o Plano de Projeto do PMBOK e rene as informaes necessrias 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. Contm as funes 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 no est neste modelo, no deve ser feito.

O modelo de casos de uso usado como fonte de informaes essencial para atividades de anlise, design e teste.

Glossrio

Conjunto consistente de definies para evitar mal entendidos. Define termos importantes usados pelo projeto. Em muitos domnios, os termos no so simples e preciso garantir que toda a equipe tenha o mesmo entendimento sobre os itens.

Disciplina Modelagem de Negcio Entender a estrutura e a dinmica da organizao cliente ou organizao-alvo, identificando oportunidades de melhoria. Trata de aspectos anteriores ao software. Antes de automatizar os processos da organizao, preciso entender o problema da organizao. Sem isso, corre-se o risco de implementar um software que no resolve os problemas da empresa e no agrega valor nenhum.

Assegurar que todos os interessados tenham um entendimento comum sobre a organizao.

Principais Papis e Atividades:

Papel - Analista de Processo de Negcios Identifica os processos na organizao-alvo e descreve estes processos para entender como a organizao trabalha. Depois define o que pode e deve ser melhorado. Em seguida prope redesenho dos processos se for necessrio. Ele est entendendo os processos de Negcio, no existe nada de software aqui.

Artefato Importante

Modelo de Domnio (modelo de objetos de negcio) Lembrando que um modelo um agrupamento de artefatos. Inclui diagramas, especificaes, entidades e etc.

um modelo conceitual e mosta os tipos de objetos mais importantes para o domnio. Como um artefado da Modelagem de Negcio, que anterior ao

software, no mostra entidades do software, apenas entidades do mundo real, do negcio.

A figura acima mostra um diagrama de classes. Essas ainda so classes conceituais de entidade e controle.

Relao com outras Disciplinas

Requisitos Utiliza o Modelo de Negcio como informao fundamental para entender os requisitos de sistema. Ou seja, os requisitos de sistema so derivados dos requisitos de negcio.

Anlise e Design Utiliza as entidades de negcio para identificar classes de entidade no projeto, que so as classes que representam a informao a ser armazenada.

Ambiente Desenvolve e mantm artefatos de suporte como o Guia de Modelagem de Negcios, que um padro que mostra como executar as atividades de modelagem de negcio na organizao.

Abmiente uma disciplina que se relaciona com todas as disciplinas do RUP. ela quem configura o RUP, estabelece guias, padres e seleciona as ferramentas a serem utilizadas. Normalmente configura guias e padres 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 so as funcionalidades descritas nos casos de uso.

Fornece uma base para planejar o contedo tcnico das iterao e para estimar o custo e o tempo do desenvolvimento do sistema. Tudo isso baseado nos casos de uso.

Principais Papis, Atividades e Artefatos: Papel - Analista de Sistemas um dos papeis mais importante do RUP. Levanta os requisitos do sistema (Atores e CDUs). Estrutura o Modelo de Casos de Uso e diagramas de casos de uso.

Papel - Especificador de Casos de Uso O especificador quem detalha a especificao dos casos de uso que foram elvantados pelo analista. Faz o passo a passo, detalha os fluxos e etc.

Artefatos Importante para o Marco

Glossrio - Explicado acima

Modelo de Casos de Uso Modelo das funes que so pretendidas pelo sistema. Serve como contrato entre o cliente e os desenvolvedores. Os requisitos funcionais do sistema so dispostos aqui agrupados em diagramas de casos de uso. Alm disso, contm

tambm as especificao dos casos de uso. Os requisitos no funcionais ficam em um artefato chamado Especificaes Suplementares, tambm da disciplina de requisitos.

Documento de Viso - Explicado acima Contm as necessidades e caractersticas mais importantes do sistema. Fornece uma base de alto nvel para que o leitor possa compreender o sistema a ser desenvolvido. No possui detalhes tcnicos.

Relao com outras Disciplinas

Modelagem de Negcios A Modelagem de Negcios fornece a entrada para a disciplina de Requisitos. Fornece as regras de negcio e um contexto organizacional para que os casos de uso sejam especificados.

Anlise e Design Usa a sada da disciplina de Requisitos como informaes primrias 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 so gerados a partir dos casos de uso. Portanto, a sada dos requisitos usada como entrada para validao do sistema. O que gera os objetivos do esforo de teste.

Gerenciamento de Configurao e Mudanas Fornece o mecanismo de controle para as mudanas nos requisitos e isso se repete nas outras disciplinas. basicamente o controle de verso dos artefatos.

Gerenciamento de Projeto Usa o Modelo de Casos de Uso para planejar as iteraes. o Plano de Iterao.

Ambiente Desenvolve e mantm artefatos utilizados nessa disciplina. a mesma coisa para as outras disciplinas.

Marco da Fase de Iniciao: Objetivos do Ciclo de Vida Marco um resultado a ser alcanado. Um estado em que se encontra o projeto e onde alguns critrios precisam ser satisfeitos. So os critrios de avaliao da fase. preciso responder sim a essas perguntas que estabelecem os critrios de avaliao.

Os casos de uso definem claramente o escopo? Que o grande objetivo da fase de iniciao.

Caso necessrio, foi possvel fazer um prottipo da aquitetura? Se no foi possvel, seu sistema pode no ser vivel.

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 condio de se fazer o projeto? Todos os interessados, os tcnicos, gerentes e usurios, precisam concluir que possvel fazer o projeto.

RUP para Concursos - Parte 5 - Fase de Elaborao e Discplina Anlise e Design Fase de Elaborao O que muda entre as fases nfase que se d em cada disciplina e o marco da fase. Na elaborao o foco na disciplina de Anlise e Design. Entretanto, pode ser que todas as disciplinas sejam de fato executadas em uma fase, dependendo do seu plano de iterao.

Na fase de Elaborao ainda existe muita atividade nas disciplinas Modelagem de Negcios e Requisitos. O esforo maior dessa fase na Anlise e Design, mas a Implementao j ocupa grande parte do esforo porque cdigo executvel j gerado para garantir a arquitetura estabilizada. Tambm comeam as atividades de Implantao.

A meta princpal da Elaborao realizar os requisitos mais significativos do sistema, com grande impacto na arquitetura e desenvolver uma arquitetura exectuvel (que funciona) e estabilizada, que garanta a continuidade do projeto. Esses casos de uso so chamados de Arquiterualmente Significativos.

A estabilidade da arquitetura avaliada atravs de prottipos arquiteturais.

Ao final da fase de Elaborao gerado uma baseline arquitetural. Baseline uma verso revisada da arquitetura ou de algum artefato.

Objetivos da Elaborao

Garangtir que a arquitetua e os requisitos estejam estveis para mitigar os riscos. "Ultrapassar esta marca (Elaborao) significa passar de uma operao de baixo risco para uma operao de alto custo e alto risco". Nas duas primeiras fases os custos so baixos, poucas pessoas esto 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 so de fato tratados. O RUP entende que estabilizar a arquitetura tratar riscos porque os piores casos de uso so implementados neste momento.

Selecionar componentes e criar planos de iteraes detalhados para a fase de Construo preciso pensar quais componentes podem ser reutilizados no futuro.

Principais Artefatos

Prottipos So usados de uma maneira direta para reduzir o risco e elicitar requistos significativos. a implementao de um conceito que precisa ser testado.

Documento de Arquitetura de Software Fornece uma viso geral da arquitetura do sistema usando as 4+1 vises (resumos anteriores) da arquitetura.

Modelo de Projeto Modelo de objetos que descreve a realizao 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 interao da UML, mostra como acontece a comunicao entre os objetos do caso de uso. uma abstrao do modelo de implementao e cdigo-fonte.

Modelo de Dados Modelo de implementao que descreve a representao conceitual, lgica ou fsica dos dados persistentes no sistema.

Disciplina de Anlise e Design (Projeto)

Objetivos Transformar os requisitos em um projeto do sistema a ser criado. Os casos de uso so 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 implementao considerando restries de tcnologia.

O nome da disciplina Anlise e Design (projeto), mas as atividades so distintas: anlisar e projetar. Anlise significa entender o problema, normalmente sem considerar as tecnologias. So modelos conceituais, sem restries tcnolgicas.

No projeto voc cuida da soluo e de modelos concretos para o problema. Leva em considerao as restries tcnolgicas.

O RUP diz que as atividades de anlise so opcionais e possvel ir diretamente para o projeto. A anlise est mais prxima do negcio e independente da tecnologia. O modelo de projeto dependente da tcnologia. Ento, o Modelo de Anlise pode ser aproveitado para o projeto em qualquer que seja a tcnologia 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 viso 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 sero feitos. Analisa os casos de uso, projeta os casos de uso e projeta os subsistemas.

Projetista de Banco de Dados Gera os modelos lgicos e fsicos da sua base de dados para guardar as entidades persistentes do sistema.

Prottipos So feitos para provar ou esclarecer algum conceito. Podem ser categorizados de algumas formas:

Quanto ao que eles exploram:

Comportamentos - enfatizam a explorao do comportamento do sistema. Estruturas - trabalham questes arquiteturais ou tcnolgicas do sistema.

Quanto ao seu resultado: Exploratrio ou descartvel - utilizado esclarecer algum requisito complicado ou nebuloso e depois descartado Evolutivo - o prottipo evoludo 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 realizaes dos casos de uso e serve como uma abstrao do modelo de implementao. (modelos so agrupamentos) Esse modelo diz como as coisas sero implementadas.

Relao com outras disciplinas

Modelagem de negcio - Fornece o contexo organizacional para o sistema. Requisitos - Fornece as funcionalidades CRTICAS a serem implementadas. Testes - Testa o sistema projetado durante a disciplina Anlise e Design Ambiente - Gera guias de anlise 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 Elaborao: Arquitetura do Ciclo de Vida o segundo marco mais importante do projeto. Considera a arquitetura executvel e a resoluo dos riscos principais. Nessa fase os riscos so resolvidos de fato e a arquitetura deve funcionar.

Critrios de Avaliao A arquitetura est estvel e robusta para comportar os requisitos atuais e futuros? Os riscos crticos foram resolvidos?

Os planejamentos de cronograma, oramento e qualidade esto bem defindos? Neste momento mais fcil dar preciso 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 Construo e Disciplinas de Implementao 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 Construo Na fase de construo a nfasa vai para as disciplinas de Implementao e Testes.

Essa fase demanda vrias iteraes e alto paralelismo na equipe. Por isso, o Gerenciamento de Configuraes e Mudanas tambm possui muita nfase durante a fase de Construo.

O esforo principal centrato na Implementao e nos Testes, mas ainda podem existir casos de uso a serem especificados. E nessa fase preciso esclarecer os requisitos restantes. A arquitetura tambm pode passar por

evolues e ajustes. Assim, as disciplinas de Requisitos e Anlise e Design tambm possuem boa atividade.

A disciplina de Implantao comea a crescer e ter mais atividades. Nela so escritos os manuais de treinamento. As verses preeliminares dos manuais e guias comeam a ser feitas na elaborao, mas na construo que isso acontece com mais nfase.

A concluso do desenvolvimento acontece durante a construo com base na arquitetura definida na elaborao.

Segundo o RUP, um processo de manufatura. Pega-se o projeto e implementa-se conforme projetado. (Na prtica BEM DIFERENTE)

Acontece tambm uma nfase no gerenciamento de recursos e controle de operaes para alcanar maior produtividade e qualidade. Essas atividades fazem parte do Gerenciamento de Configurao e Mudanas. O ambiente pode ser catico em projetos grandes e preciso uma abordagem sistemtica para gerenciar esta fase.

Objetivos Minimizar custos de desenvolvimento, otimizar recursos e evitar retrabalho. A palavra chave eficincia.

Disponibilizar as verses teis (alfa, beta e etc) com rapidez. Os testes ALFA so realizados durante a fase de Construo.

Concluir a anlise, o projeto, o desenvolvimento e o teste de todas as funcionalidades.

Verificar e decidir se o software est pronto para implantao.

Principais Artefatos

O Sistema (disciplina de implementao) - O prprio sistema executvel, pronto para iniciar os testes beta. Lembrando que os testes beta so executados na Transio.

Plano de Implantao - guia a equipe de implantao e transio para eles disponibilizarem o software. Essa apenas uma verso inicial do plano, as verses finais so feitas na Transio. Em projetos menores o Plano de Implantao pode estar embutido no Plano de Desenvolvimento de Software.

Conjunto de Testes - Testes implementados e executados para validao e estabilidade das verses (releases)

Disciplina de Implementao

Objetivos Codificar! Implementar o sistema com qualidade. A qualidade desse cdigo depende da qualidade da Anlise e do Projeto que foram feitos nas fases anteriores.

Implementar o cdigo em subsistemas e camadass. As classes devem ser pensadas em termos de componentes para favorecer a reutilizao do cdigo.

Testar os componentes desenvolvidos como unidades (testes unitrios). Testes unitrios so feitos pelos desenvolvedores e no por testadores.

Integrar os componentes gerados pelos implementadores individualmente em um build nico. O papel responsvel pela integrao o Integrador.

Papeis, Atividades e Artefatos Implementador - implementa os componentes e faz os testes unitrios. Integrador - integra os cdigos e componentes do sistema em um build nico.

Artefatos Importantes O Sistema, Componentes, Builds

Relao Com Outras Disciplinas

Anlise e Design fornece a principal entrada para a Implementao atravs do Modelo de Design (projeto). A implementao do cdigo feita a partir dessa entrada. Digramas de classes, sequncia e etc.

Teste descreve como realizar o teste de integrao de cada build. Os testes de integrao e os testes Alfa so descritos pela disciplina de testes.

Implantao descreve como utilizar o Modelo de Implementao para empacotar e disponibilizar o sistema em um ambiente, alm 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 soluo que resolve o problema levantado anteriormente? Como voc garante que esse cdigo realmente resolve o problema?

Objetivos

Localizar e documentar defeitos na qualidade do software. Testes so feitos para encontrar defeitos e nunca garantem que o sistema est livre de defeitos.

Validar as suposies feitas nas especificaes de design e requisito atravs de uma demonstrao de fato. Fala-se que so suposies porque a certeza s aparece aps os testes. No levantamento de requisitos os analistas esto supondo que esto fazendo tudo correto.

Validar as funcionalidades dos software de acordo com o projeto e verificar se os requisitos foram implementados de maneira correta.

Papis, Atividades e Artefatos

Analista de Testes quem elabora o Plano de Testes. o plano que define os objetivos dos testes para cada iterao. Se for o caso, pode ser feito um nico Plano de Testes Mestre, que serve para todas as iteraes.

No Plano de Testes existem os objetivos, a abordagem dos testes (caixa branca ou preta), os tipos de testes (desempenho, funcionais, segurana, etc). O plano tamb informa quantas pessoas vo trabalhar com isso e quais sero os documentos gerados pelos testes.

Projetista de Testes quem gera os Casos de Teste, que so gerados a partir dos cenrios dos Casos de Uso. Os Casos de Teste so especificaes de entradas e sadas, 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 - execuo, gerao de relatrios e logs de execuo dos testes.

Relacionamento Com Outras Disciplinas

Requisitos - fornece os casos de uso para a gerao dos casos de teste. Fornece a base para gerao dos testes.

Anlise e Design: fornece o projeto e a arquitetura que devem ser testados.

Implementao: produz os componentes e builds que sero testados.

As disicplinas de Suporte funcionam como nos outros resumos. Ambiente: prepara os guias, padres e ferramentas. Gerenciamento de Projetos: planeja as atvividades de testes para a iterao. Gerenciamento de Controle e Mudanas: controlar, gerencia e versiona os artefatos de testes.

Marco da Construo: Capacidade Operacional Inicial O produto est pronto para ser passado para a equipe de Transio. Todas as funcionalidades foram desenvolvidas e os testes ALFA foram concludos.

Testes ALFA e BETA so testes de aceitao do sistema. O usurio testa o sistema para aceit-lo.

Os testes ALFA so realizados no final da fase de Construo e conduzidos por um conjunto restrito dos usurios finais, os mais importantes e experintes. O teste acontece NO AMBIENTE DE DESENVOLVIMENTO. um teste controlado.

O manual do usurio produzido e existe uma descrio do release atual.

Critrios de Avaliao O produto est estvel para ser implantado? Os problemas mais graves foram identificados e resolvidos? O resultado est coerente com o planejado? Os envolvidos esto prontos para a Transio?

RUP para Concursos - Parte 7 - Fase de Transio e Discipina de Implantao Fase de Transio Durante essa fase a nfase na disciplina de Implantao. Que a disciplina que cuidaa da disponibilizao do software para o usurio final. As outras disciplinas de engenharia possuem muito pouca ou nenhuma atividade.

Outra disciplina importante a Gesto de Configurao e Mudana. Ela d o suporte para se estabelecer as verses que so implantadas para os usurios finais e os itens de configurao de cada realease.

Mais de 70% do esforo direcionado para a disciplina de Implantao. Quase tudo j deve ter sido feito nas disciplinas anteriores. O que sobra para a Transio deve ser apenas ajustes finos em funo dos testes Beta (no ambiente do usurio).

O foco dessa fase disponibilizar o software ao usurio final. Podem acontecer vrias iteraes e em cada uma delas o release testado e os ajustes so feitos de acordo com o feedback dos testes.

O feedback do usurio deve ser em relao a ajustes finos, normalmente com relao a usabilidade e visual. Os problemas mais graves devem ter sido tratados nas fases anteriores. No faz sentido mexer na arquitetura ou tratar questes de segurana neste momento.

Essa fase pode ser muito rpida, 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 so realizados para obter a aceitao do usurio, no ambiente real de produo e sem acompanhamento direto do desenvolvedor.

Treinamento de usurios e equipe de manuteno. Os usurios devem aprender a utilizar o sistema.

Atividades de ajuste: correo de erros, melhorias de desempenho e usabilidades.

Consentimento dos envolvidos dizendo que o software atende ao que se necessitava no incio.

Principais Artefatos

Notas de Release (release notes) - textos informando o que mudou de uma verso para a outra, quais erros foram corrigidos e quais so as novas funcionalidades.

Artefatos de Instalao - tudo o que necessrio para instalao do softwares: scripts, arquivos de configurao e etc.

Material de Treinamento - Guias do usurio, manuais do sistema e etc.

Disciplina de Implantao

Objetivos Coordenar e gerenciar os testes beta, que so testes de aceitao. A abordagem dos testes foi definida pela disciplina de Teste durante a construo, mas o gerenciamento dos testes feito na Implantao.

Desenvolver os artefatos de instalao e materiais de treinamento.

Liberar para fabricao (liberao e instalao no ambiente alvo)

O RUP define 3 tipos de instalao do produto

- Instalao personalizada - necessita de configurao do ambiente para o usurio. a mais complexa.

- Produto em uma forma compacta - disponibilizado em uma mdia para o usurio instalar

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

Papis, Atividades e Artefatos Gerente de Implantao - quem desenvolve o plano de implantao, tudo que precisa ser feito para a implantao, inclusive as notas de release.

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

Implementador - quem implementa os artefatos de instalao: instalador, arquivos de configurao, scripts de instalao e etc.

Artefatos: Builds do produto, notas de release, aretafos de instaslao e material de treinamento.

Relao com Outras Disciplinas

Requisitos - a fonte principaal para elaborao de material de suporte e treinamento.

Teste - testes so fundamenteias para a implantao do sistema e aceite do usurio.

Ambiente, Gerenciamento de Projeto e Gerenciamento de Configurao e Mudanas funcionam da mesma forma que nas outras disciplinas.

Marco da Implantao: Release do Produto Implantao da verso 1.0 e depois decide-se se os objetivos foram todos alcanados e se deve existir outro ciclo de desenvolvimento para gerao de uma nova verso, uma verso 2.0 por exemplo.

Critrios de Avaliaco As despesas reais com recursos so aceitveis quando se compara com o que foi planejado? O usurio est satisfeito? O sistema atende s necessidades do usurio?

RUP Para Concursos - Parte 8 - Disciplinas de Surpote

Disciplinas de Suporte - Gesto de Configurao e Mudanas Controla as mudanas feitas nos artefatos de um projeto e mantm a integridade entre eles.

Na atividade de Gerenciamento de Solicitaes de Mudana (CRM)

voc

recebe as solicitaes de mudana. Analisa em termos de impacto e risco, v o custo benefcio e aprova ou recusa a solicitao.

No Gerenciamento de Configurao voc identifica os itens de configurao, que so todas aquelas coisas que possuem valor no ambito do seu projeto e

que percisam ter a configurao controlda. Esses itens so armazenados em um respositrio. preciso manter esses itens de configurao armazenados, controlados e versionados.

Na Medio voc gera relatrios a respeito das mudanas nos itens de configurao e com isso pode responder algumas questes gerenciais a respeito do processo de mudana e configurao. Quantas mudanas esto pendentes? Quanto tempo leva para uma mudana ser implementada?

Objetivos Identificar e controlar itens de configurao

Restringir as mudanas nesses itens

Auditar as mudanas nos itens - checar se a baseline do projeto contm todos os itens de configurao necessrios.

Evitar confuses de atualizao simultnea - na fase de construo existem muitas equipes trabalhando em paralelo e isso evita que muitas pessoas atualizem o mesmo aretefato ao mesmo tempo.

Evitar Notificicao Limitada - uma pessoa atualiza um artefato que de interesse de outras pessoas, mas elas no ficam sabendo dessa atualizao.

Controle de Verso - controla as verses dos artefatos.

Benefcios

Estabilidade maior do produto, j que s as mudanas aprovadas so implementadas. Suporte a mtodos de desenvolvimento porque vrias equipes podem trabalhar ao mesmo tempo em um ambiente controlado. (isso precisa ser aprofundado)

Restrio de mudanas feitas nos artefatos, que seguem as polticas do projeto e uma trilha de auditoria que diz quando e por quem um artefato foi alterado. A gerncia tem o controle dos artefatos do projeto.

Principais Papis, Atividades e Artefatos.

Gerente de Configurao - Configura o ambiente de gerencia de configurao e estabelece as polticas dessa gerncia.

Gerente de Mudanas - estabelece o processo de controle de mudanas e aprova ou no as solicitaes de mudana.

Repositrio do Projeto e As Solicitaes de Mundana so os artefatos importantes.

Disciplina Gerenciamento de Projeto Gerenciar pessoas, equipes, fases e iteraes para executar e monitorar o projeto. Planejar o cronograma, gerenciar a qualidade e gerenciar os riscos do projeto.

Gerencia o tempo atravs do cronograma, os critrios de qualidade atravs do plano de gerenciamento de qualidade. Gerencia os riscos, que so mapeados na fase de iniciao, com a matriz de riscos e criada a estratgia de mitigao dos riscos.

Gerenciamento de pessoal, contrato com fornecedores e gesto de oramento no esto includos no RUP. Que recomenda o PMBOK para essas coisas. A viso do gerenciamento de projetos do RUP limitada.

O planejamento de projeto no RUP ocorre em dois nveis. H uma baixa granularidade ou Planos de Fase que descrevem todo o projeto e uma srie de alta granularidade ou Planos de Iterao que descrevem os passos iterativos.

Esta disciplina concentra-se principalmente em aspectos importantes de um processo de desenvolvimento iterativo: gesto de riscos, planejamento de um projeto iterativo atravs do ciclo de vida e para uma iterao particular, processo de acompanhamento de um projeto iterativo e mtricas. No entanto, esta disciplina do RUP no tenta cobrir todos os aspectos do gerenciamento de projetos.

Principais Papis, Atividades e Artefatos

Gerente de Projetos - Um papel atuante em todas as fases do RUP e com atuaes diversas. Possiu vrias atividades, dentre elas: planejar fases e iteraes, 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 Iterao - os planos para cada iterao Lista de Riscos

Disciplina Ambiente Configura o processo para o projeto de forma adequada a realidade da organizao. Customiza o RUP. O que no til para a sua organizao deve ser removido.

No Ambiente voc seleciona e adquire as ferramentas que so teis. Desenvolve ou adapta os templates para as outra disciplinas do projeto, tambm desenvolve e adapta os guias das atividades.

Oferece a organizao para o AMBIENTE de desenvolvimento de software que dar suporte equipe de desenvolvimento.

Principais Papis, Atividades e Artefatos

Engenheiro de Processo - quem vai configurar o RUP para a organizao. 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 organizao. a personalizao do RUP adaptada ao projeto. um documento dinmico. criado no incio da fase de iniciao, mas alterado durante todo o projeto. A cada iterao e fase, novas disciplinas so adicionadas a este documento.

Esta disciplina uma das mais importantes e a ausncia dela uma das maiores falhas em projetos. J que o RUP grande demais.